I read that in Hyperledger v1, encryption and channels can be used to enforce privacy.
I want to try the encryption approach to accomplish this. Since all registered users have private/public keys, I plan to use the public keys of users to encrypt some data (later I plan to combine this with symmetric cryptography to make it more efficient).
In addition, I plan to use the private key of the invoker of a function to perform decryption.
How do I get the public/private keys inside the chaincode? In addition, I also plan to perform encryption/decryption in NodeJS (outside the chaincode) since I'm using the NodeJS SDK for Hyperledger v1. How do I get the public/private keys through NodeJS?
While using NodeSDK you simply load keys from theirs location on disk and to obtain signer (client) certificate you can use API from ChaincodeStubInterface interface which provided you while chaincode is invoked:
// GetCreator returns `SignatureHeader.Creator` (e.g. an identity)
// of the `SignedProposal`. This is the identity of the agent (or user)
// submitting the transaction.
GetCreator() ([]byte, error)
First of all, I think that you should know how are those keys created. There are different ways for it, but Hyperledger Fabric gives you two tools to create these keys:
Cryptogen: this tool is used to generate the cryptographic material (x509 certs) for your network entities. These certificates are representative of identities, and they allow for sign/verify authentication to take place as our entities communicate and transact.
Fabric CA: a component of the Fabric, i.e. the CA that will issue certificates for each member.
Then, once you have the keys, you should manage them. The Fabric project makes it easier thanks to the MSP. When you create a channel, you define the public keys of the peers and the keys of the issuers of those certificates. Then, Fabric manages them to verify the transactions.
The Membership service provider (MSP) offers us the possibility of abstracting from all the cryptographic mechanisms and protocols of validation, authentication verification and signature.
Related
I have to configure RSA HSM Public and private key in the azure key vault and save the data in encrypted form.
For added assurance, when you use Azure Key Vault, you can import or generate keys in hardware security modules (HSMs) that never leave the HSM boundary. This scenario is often referred to as bring your own key, or BYOK. The HSMs are FIPS 140-2 Level 2 validated. Azure Key Vault uses nCipher nShield family of HSMs to protect your keys.
More information about generating and transferring an HSM-protected key over the Internet:
You generate the key from an offline workstation, which reduces the attack surface.
The key is encrypted with a Key Exchange Key (KEK), which stays encrypted until it is transferred to the Azure Key Vault HSMs. Only the encrypted version of your key leaves the original workstation.
The toolset sets properties on your tenant key that binds your key to the Azure Key Vault security world. So after the Azure Key Vault HSMs receive and decrypt your key, only these HSMs can use it. Your key cannot be exported. This binding is enforced by the nCipher HSMs.
The Key Exchange Key (KEK) that is used to encrypt your key is generated inside the Azure Key Vault HSMs and is not exportable. The HSMs enforce that there can be no clear version of the KEK outside the HSMs. In addition, the toolset includes attestation from nCipher that the KEK is not exportable and was generated inside a genuine HSM that was manufactured by nCipher.
The toolset includes attestation from nCipher that the Azure Key Vault security world was also generated on a genuine HSM manufactured by nCipher. This attestation proves to you that Microsoft is using genuine hardware.
Microsoft uses separate KEKs and separate Security Worlds in each geographical region. This separation ensures that your key can be used only in data centers in the region in which you encrypted it. For example, a key from a European customer cannot be used in data centers in North American or Asia.
For implementing bring your own key (BYOK) , please visit here
Hope it helps.
I have a Ruby on Rails application with a database that stores sensitive user information (hashed with Devise). I now need to pass some of this sensitive information to another internal service on another server that needs it to make calls to third party APIs, so it needs a way to request that information from the RoR app.
What's the best approach to something like this? My first intuition was to grant an internal API key that would grant access to all sensitive information in the DB (via a private endpoint), the same way developer keys give access to a subset of API endpoints. Is this secure enough as long as I hash the API key? What's the best approach to passing sensitive information around through internal services?
Private APIs
My first intuition was to grant an internal API key that would grant access to all sensitive information in the DB (via a private endpoint), the same way developer keys give access to a subset of API endpoints
Well private endpoints or private APIs don't exist in the sense of only protecting them by using an API key. From a web app you only need to see the html source code to be able to find the API keys. In mobile devices you can see how easy is to reverse engineer API keys in this series of articles about Mobile API Security Techniques. While the articles are in the context of mobile devices, some of the techniques used are also valid in other type of APIs. I hope you can see now how someone could grab the API key and abuse from the API you are trying to secure.
Now even if you don't expose the API key in a mobile app or web app, the API is still discoverable, specially if the endpoint is served by the same API used for the other public endpoints. This is made even easier when you tell in robots.txt that bots should not access some of the endpoints, because this is the first place where hackers look into for trying to enumerate attack vectors into your APIs.
Possible Solutions
Private API Solution
What's the best approach to something like this? My first intuition was to grant an internal API key that would grant access to all sensitive information in the DB (via a private endpoint)
In order to have a private API the server hosting it needs to be protected by a firewall and locked to the other internal server consuming it with certificate pinning and maybe also by IP address. In order to be able to properly secure and lock down the internal server hosting the supposed private API it MUST not support any public requests.
Certificate Pinning:
Pinning effectively removes the "conference of trust". An application which pins a certificate or public key no longer needs to depend on others - such as DNS or CAs - when making security decisions relating to a peer's identity. For those familiar with SSH, you should realize that public key pinning is nearly identical to SSH's StrictHostKeyChecking option. SSH had it right the entire time, and the rest of the world is beginning to realize the virtues of directly identifying a host or service by its public key.
Database Direct Access Solution
What's the best approach to passing sensitive information around through internal services?
Personally I would prefer to access the database directly from the other server and have the database software itself configured to only accept requests from specific internal servers for specific users with the less privileges possible to perform the action they need. Additionally you would employ the firewall locking to and use certificate pinning between the internal servers.
Conclusion
No matter what solution you choose place your database with the sensitive data in server that only hosts that database and is very well lock-down to your internal network.
Anyone needing to access that sensitive data MUST have only read privileges for that specific database table.
Is there a way to make transactions in SawTooth private?
I know HyperLedger Fabric has "channels" and Quorum has private transactions, so looking for something similar but don't see it:
https://sawtooth.hyperledger.org/docs/core/releases/latest/architecture.html
Of course theoretically one could implement encrypt/decrypt process, but this cumbersome to track (if it is an encrypted or decrypted payload)
Since Sawtooth is permissioned it is possible to set up users that have different roles and access rights. This would allow you to create transactions that are private to specific identities.
You can configure a validator to only accept transactions from identities listed in a local config file. Or, use the identity namespace to set the allowed identities, which will be checked when a transaction is received from a client or when a block is validated.
See the identity transaction family for more details of how Sawtooth manages identities and permissions:
The identity system described here is an extensible role and policy based system for defining permissions in a way which can be utilized by other pieces of the architecture. This includes the existing permissioning components for transactor key and validator key, but in the future may also be used by transaction family implementations.
The identity namespace:
Encompasses ways to identify participants based on public keys
Stores a set of permit and deny rules called “policies”
Stores the roles that those policies apply to
There is an experimental feature called Sawtooth Private Data Objects (PDO). Blockchain objects that are kept private through encryption.
For more information, see https://github.com/hyperledger-labs/private-data-objects/tree/master/sawtooth
For docs, see links in this tweet: https://twitter.com/kellymolson/status/1019299515646406656
Alternatively, you can encrypt your payload so others without a private key cannot see it in the blockchain. Or you can just store a hash/checksum in your payload.
We can use Private Transaction Families provided by the Hyperledger labs.
https://github.com/hyperledger-labs/private-transaction-families
The system is based on a generic distributed ledger infrastructure (Hyperledger Sawtooth) and an Intel® SGX (Software Guard Extensions) 'hardened' Transaction Processor which provides a mechanism to enable Hyperledger Sawtooth to contain private information that is both not publicly available but required to validate transactions.
For more information about how Private Transaction Families work, see the following link
https://github.com/hyperledger-labs/private-transaction-families/blob/master/SPECIFICATION.md
I'm receiving a secret encrypted with Key A, and need to send it somewhere else encrypted under Key B.
Both keys can be symmetric or asymmetric - but I'd like to achieve this within the vault itself (first prize) - (avoiding a decrypt, having the secret in the clear, then an encrypt).
Is this possible with Azure Key Vault? If not, any workarounds?
Thanks.
As far as I am aware, at this point in time, it is not possible with the current Key Vault API's. The way I think of Key Vault at this point in time is it's just a tailored service for storing and gaining access to Keys, Secrets, Certificates and managing applications and users that can access them (with some fancy bits on top).
You will need to decrypt and re-encrypt somewhere outside of Key Vault.
One possible workaround though given you are in Azure is to create an Azure Function to do this work. At least then the process of the translation happens inside an isolated Function context (in Azure). The beauty of using an Azure Function is that you could do this with minimal code and without a full application, but you would need to ensure that Function can only be utilised by you.
A possible workflow could be:
1) If Key A is not in Key Vault, upload it.
2) If Key B is not in Key Vault, upload it.
3) Run Azure Function with inputs for Key Vault identifiers for Key A, Key B and A(Secret). Do the conversion and then the Function could store B(Secret) in Key Vault (or another Key Vault if you have access to one).
Alternatively it could just output the new encrypted secret.
C# Key Vault Client:
https://learn.microsoft.com/en-us/azure/key-vault/key-vault-use-from-web-application
An example of Azure Function and Key Vault in C# for reference: http://www.rahulpnath.com/blog/azure-key-vault-from-azure-functions/
I have developed a 'REST-like' XML API that I wish to expose for consumption by third-party web applications. I'm now looking to implement a security model for the exchange of data between a third-party application and the 'REST-like' XML API. I would appreciate suggestions for a suitable asymmetric encryption model.
If you want encryption why not just use SSL to encrypt the connection rather than encrypting the response data? If 128-bit SSL isn't sufficient, then you'll either need to integrate some existing PKI infrastructure using an external, trusted authority or develop a key distribution/sharing infrastructure yourself and issue your public key and a suitable private key/identifier to your API consumers. Choose one of the cryptography providers in System.Security.Cryptography that supports public/private key exchange.
HTTPS works with asymmetric key encryption. It is well-known protocol easy to implement.
It protects against 3p intrusion in your communication.
All you need to implement "below" is authentication - to make sure your user known to you.
Common thing to do is to provide users with key that needs to be sent with every request.
Most common is to implement the OAuth protocol. This is what is used for the OpenSocial providers that checks authorization with 2-legged and/or 3-legged oAuth
Just do some google search and you will find a lot of implementations.