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.
Related
We have some characteristics that are marked bonded/encrypted and some that are unbonded. Obviously if we have two unbonded devices, communication over the unbonded characteristics will not be encrypted, but does that change once bonding has occurred? Once the two devices are bonded, are all communications encrypted (even those over unbonded characteristics)?
The whole link is either encrypted or not so either all data is encrypted or none.
When a Bluetooth stack supports "marking" a characteristic with a specific security level and the link does not currently meet the required security, it will try to take the required actions to make the link meet the required security level and then try again. That means either start encryption if the devices are already bonded, or initiate pairing.
Note that even if two devices are bonded and posses a shared encryption key, that doesn't necessarily mean that the link will automatically be encrypted when a connection starts since it's not mandatory to encrypt the link.
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.
Eddystone-EID beacons transmit Ephemeral Identifiers which will be resolved by Google's Proximity Beacon API. This means one can not detect an Eddystone-EID beacon without an active internet connection. The approach is pretty new, so there is not much info on the internet.
Generation of ephemeral identifier and resolving mechanism is described in this paper provided by Google researchers. Here is the summary of the procedure: Eddystone-EID beacons encrypt the value from their embedded time counters with AES-128 using their key, while the key is unique identifier for each beacon. The result is the ephemeral id that's goning to be transmitted. Like every 512 secs, beacons recomputes their ephemeral ids. When an ephemeral id received by the receiver side, the resolver tries to find the key which provides correct decryption among known predefined keys. The found key corresponds to identification of the beacon.
I'm wondering whether it's possible to implement an offline resolving/decryption procedure according to given paper, that works with Eddystone-EIDs on the market. Instead of using a global resolver at the cloud, can we develop a local resolver which works with much less number of beacons?
If yes, is there any previous attempts or implementations etc?
What's your opinions on this topic?
Yes, it is theoretically possible to implement an EID resolver in Android or iOS code that does the calculations to see if an EID transmission comes from a known beacon transmitter.
The mobile device implementation would need to use compatible AES-128 encryption libraries and somehow store copies of the keys needed to do the resolution for each beacon.
When building a server-side resolver implementation for testing purposes, I considered building such a library. I also learned it is very tricky to get everything exactly right. Many AES libraries only provide partial functionality so are unusable.
It is also important to note that US export restrictions on encryption software will make putting apps that do this in the Apple AppStore and Google Play Store problematic.
Realm supports encrypting the database file on disk with AES-256+SHA2 by supplying a 64-byte encryption key when creating a Realm.
Since the Realm Mobile Platform is self hosted (inhouse or via cloud) - does that effectively also mean that this same database file encryption is available ? I'm assuming 'yes' but since I was always taught "never assume" I wanted to ask the question here.
Yes, the same encryption is also available for synched Realms. However, note that if you supply an encryption key to the SyncConfiguration only the local file is encrypted, not the file on the server or other devices. You would need to supply the encryption on each of these as well.
This also means that it is possible for one device to encrypt the data and send them to a device that saves them unencrypted.
On the wire we use TLS if you enabled it (which you should).
I'm trying to understand the mechanism of encryption used on the web.
One thing is not clear to me at this point:
If I check, for example, google.com certificate, I can see that the public key is 4320 bits long, but Chrome shows that the connection is encrypted using AES_128_GCM, that I would expect to work with 128 bit keys.
What am I missing here?
The 4320 bits in the public key algorithm are used to encrypt the 128 bits in the symmetric key algorithm. The public key establishes a secure channel of communication between two parties who initially don't have any shared key. Think of this as a low bandwidth channel, which isn't very useful due to the computationally expensive nature of the public key algorithm. In practice -- the sole use of this public-key is to communicate a shared key to establish a high bandwidth channel which uses something like AES (which requires both parties to have the same key). The overall process is an example of a hybrid cryptosystem.
The whole process is more involved but here are the basis to answer the question.
The data is encrypted with a symmetric algorythm such as AES, it is fast, secure and can handle any length of data.
The symmetric key is encrypted by an asymetric algorythm sucb as RSA or EC, they are slow and the data length is limited by the key length.
There are many articles on the Internet about HTTPS, it can get quite complicated.