I will demonstrate my question with an example.
I want to develop a distributed application for renting cars. Since the booking details (BD) can be visible on the blockchain, I want to encrypt them and be accesible only by the intended users. Assume that the car owner and the renter have public key and private key, the car has a key (symmetric encryption) and that the onwer and the renter have agreed beforehand on the BD.
The idea is that the owner will generate an access token, from the BD, which will be published on the blockchain, retrieved by the renter and used by him to enter the car.
My question is how can I encrypt the BD in order to generate the access token while at the same time confidentiality, integrity and availability can be maintained.
One ill-solution that I have thought is that the owner encrypts the BD and their signature with the car's key (in order to generate the access token). Then he publishes the access token to the blockchain and retrieved by the renter. However, how can the renter know that the access token contains the agreed BD? Is it good practice to use a second layer of encryption such that; after the owner generates the access token he encrypts it together with the BD with the renter's public key? In this scenario, when the renter decrypts it, he has two things, an access token (which will be used to enter the car) and the booking details (verify that these are the agreed BD).
Is there a more efficient or elegant way to do this?
Thank you in advance.
Related
I need to protect a group of user’s data, i.e. to facilitate multiple invited users to read and contribute protected data.
My understanding is that I need to implement the following design:
1 . Each user gets authenticated with Firebase Auth (OAuth2 or email/password).
2 . Each user creates a public/private key-pair (How?). The public keys can be shared in Firebase. How to store the private key? Seems natural to store it in Firebase in encrypted form (passcode protected), but how?...
2a. Either the users must manually store the passcode in e.g. a “personal password manager”. Password protect private key
2b. Or could the passcode come from e.g. the OAuth 3rd party?
3 . Encrypt/decrypt data (support user group). Multi-user-data requires an extra layer for having a common (symmetrical) key (How?), so all invited users can encrypt and decrypt data. The group manager stores this common key in Firebase to all users, using their individual public keys. Virgils story about the Creator.
So does the above requirement make sense(!), and how to get around compliance? How to document such security measures? Protecting your customer’s data might make you sleep at night, but you also need to convince the future customers that data will be safe.
I wonder why Firebase does not have a guide on all this, to safely facilitate GDPR. The topic seems such a show stopper nowadays.
All constructive input are highly appreciated!
There are many end-to-end encryption protocols in use, with Signal being one of the more popular ones. Aside from being rather complex, I'm not entirely sure Signal is better than some less complex protocols. Giving it some thought, I want to see if the following protocol (something I made up), is a feasible alternative. This protocol may already exist under some known name. If it does, please let me know.
The goal, as for any end-to-end encryption, is to encrypt data at the source location and decrypt it at the target location. Private and public keys are needed whereby the public key is used to encrypt the data and the private key is used to decrypt data. What end-to-end encryption does not support is verification, meaning that you cannot know for certain whether the person sending or receiving the data is who you believe them to be. If the data being sent is just chat messages, there is no real way of knowing whether you are chatting with the real person you believe you are. However, if the data is a live video stream, you can almost be certain you are dealing with the real person, although this can also be circumvented if the person has an identical twin, or the person is an imposter that just happens to look and sound like the real person.
The protocol I am describing here takes into account the need for verification, when it is possible to provide it.
Let's assume that we are dealing with two people: Alice and Bob. Alice wants to initiate a chat discussion with Bob. A backend server is used to act as the middle man that facilitates communication between the two people. Ultimately, the design of the end-to-end encryption protocol is to have the server play a minimal role in the communications. This means that the only data that the server should store are public keys and encrypted chat messages. It needs to store these since it is possible that one of the persons is not online and the chat messages need to be forwarded to them as soon as they go online.
When Alice wants to initiate a chat discussion with Bob, she needs to obtain Bob's public key in order to encrypt the chat message. We'll assume that Bob is about to use the app for the first time and then signs in with the backend. Bob's device generates a public key that gets stored on the server. This public key however contains some encrypted data that identifies Bob's device. Bob could be using a smartphone or a computer. Let's assume he's using a smartphone. The smartphone could have a unique identifier that uniquely identifies it from all other devices in the world. This could be a hardware identifier or even a random number that the app generates. When Bob's app goes to create the public key, it will include this identifier within the key and it will be encrypted. Whenever Bob's device receives an encrypted message from Alice, it can use his private key to decrypt the message and obtain the unique identifier. If the identifier matches with the one from his device, he can be certain that his public key was used to encrypt the message.
Until Bob's public key gets stored on the server, Alice cannot send any chat messages. All Alice would see on her device would be a status message indicating that the connection to Bob is still pending. Once the server has Bob's public key and Alice is online, it will forward the key to Alice. Like Bob, Alice has also created a public key which contains a unique identifier that identifies her device. This key is also stored on the server.
At this point, the initialization for end-to-end encryption is complete. Alica and Bob can now start to send chat messages to each other.
Alice sends a chat message that is encrypted with Bob's public key and sent to the server. The server will then forward it to Bob's device. After decrypting the message, Bob's device verifies that the message contains the unique identifier that belongs to his device. If the identifiers match, then the message had to have been encrypted with Bob's public key.
So the server has sent an encrypted message to Bob indicating who it is from (each person's user ID is used to indicate who they are). But Bob can't really be certain that it really is from the person that the server says it's from. After all, if you had a man-in-the-middle hacker, they could obtain the public key and send a message to Bob using Alice's user ID. To solve for this, we need to take a step back to the initialization phase. When Bob's device received a request to connect to Alice, it began to create a public key and included a unique identifier that got encrypted into the key. But in addition to this device ID, Alice's user ID is also included. So when Alice goes to send a chat message and Bob's device decrypts the message, it can obtain the sender ID. It can then compare the user ID that the server provided with the user ID encrypted in the message. If the two match, it most likely means that the message did originate from the same person. This however does not prevent a man-n-the-middle from obtaining Alice's public key and sending chat messages to Bob using Alice's ID. That's why verification, as described below, is important.
This means effectively that for every person Bob wants to communicate with, a unique public key is used for each person.
There is however the case where anyone can have multiple devices. When a chat message is sent, it needs to be sent to all of their devices. However, since we already decided that each device must include an encrypted device ID within their public key, any additional devices can't use the same public key. If they did, as soon as they decrypt a received message and check the device ID, it will discover that it does not match with their own device ID and the message will be rejected.
One solution to this is to repeat the initialization for each device. In essence, you are treating each device as a unique person, even though two or more devices can belong to the same person. But even though they belong to the same person, for the purpose of strict security, they really should be treated as belonging to completely different people. Even though each device acts like a different person, because the public key contains the encypted user ID, the recipient's device will notice that the user IDs are the same and use this when displaying the message from that person.
This is the basics of the end-to-end encyption. It doesn't offer any verification as to whether the person sending chat messages is the real person. Apps like WhatsApp that use Signal allow two people to compare some unique identifiers stored on each device to allow them to verify that they match up with the identifier on the other person's device. For this to work you need to have both persons compare the code on their device with the code on the other device using their eyes. Since both persons are physically seeing each other and have verified that the codes match, then the codes must be valid. These codes are actually part of the public keys used to send and receive data. If the codes don't match, then it might mean that the person that they thought they were communicating with was not the real person. WhatsApp makes this comparison easy by creating a QR code that the other person can scan with using their device. There's no need to physically read and compare a very lengthy set of numbers.
An alternative way of verifying someone is to use a video stream where both persons see each other and can confirm their identities. Instead of sending a chat message, a video feed is initiated between the two. At the start of the feed from both sides, an encrypted video message is sent from both sides. This doesn't have to be a chat message that is shown to the user. It could be the first video frame encrypted or it could just be some arbitary data indicating that the message is intended for verification purposes. The public key used to encrypt chat messages is used to encrypt this message as well. As soon as both persons see each other, a message pops up on the screen asking whether the person they are looking at is the real person. If the person agrees that the other person is the real person, they can confirm it and that person's public key will be marked as verified. This marking occurs on the device and is stored in cache. Whenever the user ever goes to chat with that person in the future, they would see a checkmark or some "verified" icon next to the person's name indicating that they have been verified.
I'm pretty sure I've overlooked something in all of this and would be grateful for any flaws that can be pointed out.
Hi Hyperledger Experts:
In some cases, some organizations in a channel have the requirement to encrypt their data on the fabric network. Please refer to https://hyperledger-fabric.readthedocs.io/en/latest/chaincode4ade.html#chaincode-encryption . And the AES encryption key and decryption key are needed.
So there is a need to store some organizations' encryption key and decryption key. The fabric documentation also mentioned "If you encrypt the data then you will need to provide a means to share the decryption keys". Please refer to https://hyperledger-fabric.readthedocs.io/en/latest/Fabric-FAQ.html
So the question is: what is the advisable way to store the AES encryption/decryption keys? Where to store them?
Apart from fabric network, do we need a separate centralized database to store them? Or can we directly store them on fabric network, and only let specified organizations to get them? Thanks very much!
I'm not an expert in data security but I believe your problem can be solved using Private Data present in hyperledger fabric framework itself.
It is confidential data that is stored in a private database on each authorized peer, logically separate from the channel ledger data. Access to this data is restricted to one or more organizations on a channel via a private data collection definition. Unauthorized organizations will have a hash of the private data on the channel ledger as evidence of the transaction data.
Refer to docs to understand how to use this to store your AES keys.
I am developing a web based application that will be employed by numerous third party organisations
in numerous countries around the world.
The browser based client will feed sensitive data into a shared back end database.
All organisations in all countries will Read/Write data into the same database.
I wish to encrypt the data entered within the browser so that its safe while in transit
to the back end database. e.g. client side encryption.
I also wish to encrypt the data while at rest in my database.
This application will be developed using Java, Javascript (REACT.js), and Scala.
The backend database will be MongoDB.
I cannot find a good Key Management example/description e.g. how a key is properly generated,
distributed, stored, replaced, deleted, and recovered during its life time.
I have the following choices/decisions to make:-
Flavour of encryption, e.g TripleDES, RSA, Blowfish, Twofish, AES etc..
Key(s) Symmetric/Asymmetric and its/thier length
How should I securely distribute the keys to my clients.
How to keep my keys safe on my back end servers.
If keys should have a lifecycle of generated, distributed, stored, replaced, deleted.
How do I decrypt data that was encrypted with Key0 when I am now using Key1, or Key2?
How should I store my multiple keys for my multiple clients to enable me to encrypt/decrypt
each clients data.
Use HTTPS with certificate pinning to secure the data in transit.
Use AES for encryption. Do not use TripleDES, RSA, Blowfish or Twofish in new work.
Use an HSM.
Encrypt the data with a long-life key that is not distributed, encrypt that key with short life keys that can be changed as needed.
Considering the scope of the project get a cryptographic domain expert to design the security and vet the code.
For a security application I want to do the following:
Each data related to a user is encrypted with this user's key (the key is unique for each user).
The only data that are not encrypted are password (because it's already hashed, no need to crypt it on top of that), email (identifier for login) and the key (to decrypt data on server side).
The goal is to make data storage safe even if my database gets full dumped, since the attacker will have to find which algorithm(s) is used for the encryption, for each user, even if he has the key.
I'm making a RESTful API connected to this database, and I want to use Spring Data neo4j + spring Rest and Spring boot (just going to do API mapping by myself, since all my attempts to let spring generate API implementation failed).
So, the real question is How to encrypt/decrypt data in SDN's transactions? I mean I need to store data encrypted, and return it decrypted, so I need to be able to encrypt it on Java side.
If I can't do it with SDN, I'll do it using Neo4j Core API instead, just wanted to give SDN a chance since it can be really time saver.