must all nodes in a given corda network use the same HSM providers? Or is it possible that certain nodes use provider A, some of them use provider B, and the others opt to store their private keys in their local node? Thanks.
HSM support for node's private keys is on the node base. As long as it is supoorted by Corda's HSM list, it will be ok.
Find more information about HSM support at https://docs.corda.r3.com/cryptoservice-configuration.html
First time learning about Corda? Join the Corda community at slack.corda.net!
Related
According to the Corda Network documentation https://corda.network/participation/distinguishedname/
A X.500 must be unique within Corda Network. The combination of O and OU are used for the uniqueness check, and the other fields are considered as attributes of the identity.
Is this uniqueness check specific to the Corda Network or does it also apply to private Corda Networks? Within the Corda Network is it unique across all zones?
If not then what are the X500 name uniqueness checks for X500 names of:
CENM networks
Bootstrapped networks
The uniqueness check is enforced on any network, including the Corda Network (tCN) and any other private Corda Networks. And it needs to be unique across all zones.
That is, the X500 names need to be unique across zones regardless of deploying on the tCN or any private network (using CENM or bootstrapper).
The reason is that the same identity manager is used for all zones across the network and the uniqueness is checked on the identity manager level. Also, A bit future thinking on the network, clients might consider subzone merging / cross-zone interop, and etc. So this grants them the flexibility and ability to achieve that in the future.
To further address your questions: How would you enforce uniquessness checks on bootstrap network and CECM networks?
The CENM Identity Operator will have built-in checking to enforce the uniqueness check. With newtwork boostrapper, there is no uniqueness check, so use it with caution.
Corda doc says
"Admission to the network
Unlike traditional blockchain, Corda networks are semi-private. To join a network, a node must obtain a certificate from the network operator. This certificate maps a well-known node identity to:"
I have a few questions about how corda netowrk is desined.
How network is partitioned.
Can all corda instance form one network? Or, are there several networks that can be connected?
Who is network operator?
Is it one party? Can that operator dominate network arbitrary?
Is Notary included in network?
Is Notary a component of network, or can notary notrize several corda netowrks?
Does network operator authorize notary, or trust notary?
A Corda network is a set of well identified legal entities. When you want to join a network you sign a legal document (participation terms of use) and then you submit something called Certificate Signing Request; once it's approved your node automatically downloads the required certificates that identify it on that network and allows it to become discoverable by other nodes so it can interact with them.
Corda network is an example, and I recommend that you go through their website: https://corda.network
In the case of Corda network, the operator is a consortium; not one organization.
That link I shared, will answer all of your questions:
Participation: https://corda.network/participation/index
Governance: https://corda.network/governance/index
Types of networks in Corda network: https://corda.network/participation/network-choice
Notary: https://corda.network/participation/notary-considerations
Can there be just a single node (not even a notary) in the corda n/w?
If yes, can the single node execute corda flows that will have the single node both as sender and receiver?
Theoretically Yes, you could have a single node that serves both as a transacting party as well as a notary. For executing flows yes it can self-issue and consume states as well.
Practically, I do not see any implication of such a network, why use DLT for such use-case.
The Cloud IOT online documentation page "Device Security" describes a device provisioning process where a "Provisioner" creates a key pair, and distributes the private key to the Device. They go a step further and recommend using a revolving key strategy for added security. All steps in this device creation process can be automated using IOT core API's, with the exception of the key distribution step.
This alludes to there being a way to safely create the key pair, and transmit the private key to the device programatically for thousands of new devices rather than by hand for each device. Similarly there must be a way to generate and transmit new key pairs in the revolving key strategy.
Any suggestions on how to do this? Perhaps there is a standard method that I am not aware of. Thanks in advance for any feedback.
This alludes to there being a way to safely create the key pair, and
transmit the private key to the device programatically for thousands
of new devices rather than by hand for each device.
I believe the language here is deliberately less specific to allow room for cases when a device builder has a secure or unique way (e.g. encrypted radio) of transmitting keys to devices. In many cases, you will have a hardware-specific or OS-specific solution for updating device firmware and this mechanism is the best approach and allows you to revoke and recover compromised devices.
I think there are really two core buckets of approaches to distribution of the private key to a given device:
Distribution / initialization at manufacture / late-manufacture stage (secure)
Distribution post-manufacture (e.g. after device has been purchased / installed / deployed)
For distribution at manufacture or late manufacture, you generally are going to be installing the keys to the device using something that is physically connected to the device in a secure environment. At manufacture, I would imagine at the manufacture facility the (contract) manufacturer calls the API using delegated credentials to send Google the public key and then securely installs the private key on device. At late manufacture, the same registration process and secure installation of the private key occurs, it's just done outside of the manufacture facility by the person contracting to manufacture the device.
In both cases of device registration at manufacture, you can register multiple certificates per-device so that you can "change your password" effectively over time by rotating through the certificates associated to the device by expiring certificates or can revoke suspicious certificates, using additional on-device credentials. In some circumstances, this is good because if only one of the on-device credentials leaks, you can switch to an on-device, secured-at-manufacture alternate. There is a minor trade-off to this approach in that if multiple credentials for a given device can leak, you will have the banal risk of having multiple credentials leak at once. And this leads us to the second bucket of key distribution, post-manufacture.
For distribution of the private key after manufacture, it gets a bit more complicated because you're effectively creating another channel for devices to be managed in your registry. For this reason, it's difficult to advise on what to do should you not have an established secure channel for completely recovering a compromised device remotely.
I'm looking for a distributed hash table to store and retrieve values securely. These are my requirements:
It must use an existing popular p2p network (I must guarantee my key/value will be stored and kept in multiple peers).
None but myself should be able to edit or delete the key/value. Ideally an encryption key that only I have access to would be required to edit my key value.
All peers would be able to read the key value (read-only access, only the key holder would be able to edit the value)
Is there such p2p distributed hash table?
Would the bittorrent distributed hash table meet my requirements?'
Where could I find documentation?
You don't need encryption, you need signatures.
The mainline bittorrent DHT does not allow arbitrary key value storage at the moment, only key -> IP:Port storage where the IP is fixed to the originator of the storage request. The vuze DHT on the other hand does support binary blob storage, on top of which you could implement some signature scheme.
Update: BEP44 added signed or hash-based key-value storage to the bittorrent DHT. But it imposes some restrictions what can be used as keys to randomly distribute data throughout the keyspace.