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
Related
In our Stream Analytics Job we have some constant values that are required for further computations. Those are considered "secret" by our customer, so it would be good to not have them set directly in the Query or the User Defined Function we're using. Is there any best practice how to deal with these, e.g. can we somehow retrieve these values from Azure Key Vault?
Unfortunately, Azure Stream Analytics don’t support Azure Key Vault bindings.
I would suggest you to vote up an idea submitted by another Azure customer.
https://feedback.azure.com/forums/270577-stream-analytics/suggestions/35328418-enhance-security-for-asa-managed-services-identit
https://feedback.azure.com/forums/270577-stream-analytics/suggestions/40530247-azure-key-vault-as-reference-data-input
All of the feedback you share in these forums will be monitored and reviewed by the Microsoft engineering teams responsible for building Azure.
You could try to see if Reference Data option in Stream Analytics could be the place where you store the constants and update often. If the concern is about having control over how your queries get encrypted while using ASA, you can use your own storage account to store all private data assets related to the job. And then encrypt your storage account in whatever approach you see fit.
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.
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.
Currently in Hyperledger Fabric 1.0 there is a central membership service. I want a way to make it decentralized so that atlas 50% of the members have to agree for a new member to join the network. How can I achieve this?
The idea is basically put the membership logic in chain code and let member service fetch data from chain code at the time of enrollment. But how to enforce this, I mean how do we know that membership service is actually reading from blockchain and not cheating.
This is actually natively support by Hyperledger Fabric, and the behavior you describe is actually the default for channel membership changes.
Each channel begins life with a genesis block. The contents of this genesis block define the channel members, as well as policies for which users from these organizations are authorized to perform different functions on the blockchain. For instance, some users may be allowed to submit transactions, but not read the whole blockchain, while others could do both.
To change the channel membership, you submit a channel reconfiguration transaction. This transaction specifies the new membership, and must include enough signatures to authorize this modification. By default, this is signatures from the admins of a majority of the organizations.
The policy framework is actually quite powerful, and with a little knowledge, you can define even more powerful rules. For instance, you could require that OrgA and 3/10 other organizations sign off to change membership. Or, you could require that all but one Org agree to make any membership change, or an infinite number of other permutations.
Some links you might find helpful:
http://hyperledger-fabric.readthedocs.io/en/latest/configtxgen.html
http://hyperledger-fabric.readthedocs.io/en/latest/policies.html
http://hyperledger-fabric.readthedocs.io/en/latest/configtx.html
The documentation and tools around reconfiguration are a little lacking at the time of this writing. The most useful place you can probably look is:
https://github.com/hyperledger/fabric/tree/release/examples/configtxupdate
There are two protobuf structures you must familiarize yourself with, the common.ConfigUpdate, and the common.Config. Channels are created by submitting a signed config update to the ordering service, which generates a corresponding config embedded in the genesis block.
The policy which governs membership changes for a channel is specified as the mod_policy field of the Application group, which is a subgroup of the Channel group. This field defaults to Admins, which refers to the policy definition Admins within the Application group. By default, this policy is set to MAJORITY of the Admins policies for the organization groups defined under the Application group.
So, to modify this policy before creating your channel, you would decode the configtx to JSON using the configtxlator tool, make your modifications, and then encode it back using the configtxlator tool once again. Submitting this new transaction will create the channel with the policy you specified.
If you wish to modify membership after the fact, the process is similar. Retrieve the current channel configuration, decode and modify it, then use configtxlator to compute a config update structure which represents your change. Gather signatures via peer channel signconfigtx then submit it to modify your channel's configuration.
This process is obviously all a bit manual at the moment, but in the future, common tasks should be automated by the SDKs and the tooling should improve as well.
Note: configtxlator is a REST service so that it can be accessed conveniently from inside your SDK application, independent of language.
As a quick addendum. You asked how you can be sure that no one is 'cheating' and not really getting the required signatures. This is also built into the system. All changes to the channel configuration are validated not only by the ordering network, but by all peers in the system. If a configuration arrives which cannot be validated, then all nodes in the network will notices, and will halt usage of that channel until corrective administrative action is taken.
For decentralised membership, that is not dependent on a centralized CA, take a look at Blockstack.
Is it possible to allow for someone in hyperledger rights only to read, and to others read+write?
So, can you specify different roles for users?
I'm going to answer the question based on Hyperledger Fabric v1.0.0.
The short answer is yes.
There are a couple of areas to discuss:
1) Ability to send (broadcast) and receive (deliver) transactions to/from the ordering service.
As you know, in order for transactions to make it to the ledger, they must go through an ordering service. An ordering service can be divided up into channels (in simplest terms think of channels as being unique ledgers). Each channel has policies which define who is able to read and write from/to the channel. The documentation on this topic is being updated, but basically there are channel reader and writer policies. If you cannot "write" to the channel, you cannot submit transactions to the ordering service. Additionally, if you don't have access to write to a channel, you cannot send endorsement proposals to peers for chaincode which is deployed on channel you don't have write permission for.
These policies are all part of channel configuration transactions (for which the documentation is currently being updated / created).
2) Chaincode
Beyond the channel-based policies mentioned above, it is also possible to restrict access to chaincode functions as well. This is actually typically handled from within chaincode itself and it is up to the deployer / developer of the chaincode to handle this (especially in the current 1.0.0-alpha release). There is some additional work underway to add some access control libraries which will make doing this a lot simpler