Security Concepts - Hive2Hive/Hive2Hive GitHub Wiki
In this section, the most fundamental security concerns and aspects, which are considered in the Hive2Hive project, are presented.
User Protection
User Credentials
So as to protect a user in the P2P network, she is required to provide a set of parameters:
- User ID - Unique identifier of the user in the network. This parameter is public.
- User Password - The password of the user to login. This parameter must be kept secret.
- User PIN - A per-password PIN of the user. In case the user password changes, it is required to change as well. This parameter must be kept secret.
In Hive2Hive, the set of these three parameters is referred to the term user credentials. The different parameters are required in different applications of the library in order to ensure a user’s privacy.
The user ID is used for the following:
- Serves as Location Key for the User Locations.
- Serves as Location Key for the User Encryption Public Key.
- Serves as Location Key for the User Profile Tasks.
User Profile Protection
All information about a user is stored in the User Profile. Hence, it is of utmost importance to protect this profile as it contains all security keys needed by the user.
User Profile Encryption
To keep the content of the User Profile private, it gets symmetrically encrypted as soon as it is put into the DHT. The according AES encryption key is derived from the user’s password and PIN by means of the PBKDF2 key derivation function. For that matter, the PIN is used to generate a fixed ‘local’ salt (as opposed to client-server systems where the salt resides beneath the hashed password on the server side). The salting is required to counter attacks that fetch a user profile and try to crack the encryption password by brute-force dictionary attacks. (Because this library is open-sourced, the key derivation function is known to everybody.)
User Profile Location
Another improvement in protecting the User Profile from unaithorized access is to hide it in the DHT. It should not be possible for an attacker to download and crack a very specific user profile. Therefore, the profile’s location is derived from a hash, out of a combination of all User Credentials. Doing it this way prevents a potential attacker to attack a specific user and instead can only fetch profiles of random users. However, the cracking of an encrypted user profile of an unknown user would be very improvident.
Encryption
User Encryption Key Pair
Since different users might want to interact over the network, a mechanism is needed to guarantee a secure connection (e.g., to prevent Man-In-The-Middle Attacks) or to encrypt data before it is sent over the network.
Each user owns a personal User Encryption Key Pair that is created during the initial Registration and stored in the User Profile.
User Encryption Public Key
In Hive2Hive, the public key of a user's User Encryption Key Pair is referred to as User Encryption Public Key and is published publicly in the DHT, such that everyone can find it. It is used to encrypt data that will be decrypted with the User Encryption Private Key.
Deriving the Location Key for this key is achieved by hashing the User ID.
This key is used for the following:
User Encryption Private Key
In Hive2Hive, the private key of a user's User Encryption Key Pair is referred to as User Encryption Private Key and is kept secret in the User Profile. It is used to decrypt data that was encrypted with the User Encryption Public Key.
This key is used for the following:
File Encryption Key Pair
Hive2Hive provides a per-file encryption for all files in the network. Before getting stored in the DHT, each file is split up into multiple File Chunks, each of them using this exact per-file file encryption key pair.
This file encryption key pair is stored in the File Index of the file.
File Encryption Public Key
In Hive2Hive, the public key of a file's File Encryption Key Pair is referred to as File Encryption Public Key and is stored in the File Index of the file. It is used to encrypt data that will be decrypted with the File Encryption Private Key.
This key is used for the following:
- Data Encryption of the Meta File of a file.
- Data Encryption of all File Chunks of a file.
- Serves as Location Key for the associated Meta File.
File Encryption Private Key
In Hive2Hive, the private key of a file's File Encryption Key Pair is referred to as File Encryption Private Key and is stored in the File Index of the file. It is used to decrypt data that was encrypted with the File Encryption Public Key.
This key is used for the following:
- Data Decryption of the Meta File of a file.
- Data Decryption of all File Chunks of a file.
Encryption of Data
The encryption of data depends on what the data represents. This is due to the fact that different data needs to be found and accessed in different ways or might even be decrypted by more than one user. See the table below to see the different encryption approaches.
Currently, the Hive2Hive library discriminates the following encryption modes:
- AES, symmetric encryption (128 bit, 192 bit or 256 bit)
- RSA, asymmetric encryption (512 bit, 1024 bit, 2048 bit or 4096 bit)
- AES + RSA, hybrid encryption
Hybrid encryption is recommended for large data as it improves the encryption/decryption time by a factor of ~1000. First, the content is symmetrically encrypted with a generated random initialization vector (IV) and a generated AES key. Then, these two encryption parameters are asymmetrically encrypted with the RSA public key.
| Data Object | Encryption |
|---|---|
| User Profile | Symmetric with password and PIN (256 bit) |
| User Locations | public, not encrypted |
| User Encryption Public Key | public, not encrypted |
| Meta File | Hybrid with RSA (2048 bit) and AES (256 bit) |
| File Chunk | Hybrid with RSA (2048 bit) and AES (256 bit) |
Encryption of Messages
Securing the communication in a P2P network is necessary when investigating the layers below. When TCP is used, the session is not necessarily secured. In case of UDP, a connection-less protocol, packet arrival is not verified and encryption at the application layer must be applied. Intermediate routers and Internet Service Providers (ISPs) could read and manipulate the message (Man-In-The-Middle Attacks). Encrypting the messages requires additional computation power but provides better security and privacy.
The User Encryption Key Pair is used to secure all communication between different users and between different clients of the same user.
All messages in Hive2Hive are encrypted in a hybrid manner.
- AES, 256 bit key length
- RSA, 2048 bit key length
The message content is symmetrically encrypted with a generated random initialization vector (IV) and a generated AES key. Then, these two encryption parameters are asymmetrically encrypted with the RSA public key of the receiver.
| Message Object | Encryption |
|---|---|
| Notifications | Hybrid with RSA (2048 bit) and AES (256 bit) |
| User Profile Tasks | Hybrid with RSA (2048 bit) and AES (256 bit) |
Authentication
User Authentication Key Pair
In order to ensure authenticity, data that is stored in the network, as well as messages traversing it, are signed by owner or sender, respectively.
Each user owns a personal User Authentication Key Pair that is created during the initial Registration and stored in the User Profile.
This key pair is used for the following:
- Data Authentication of the User Profile.
- Data Authentication of the User Locations.
- Data Authentication of the User Encryption Public Key.
- Data Authentication of private (not shared) content, such as Meta Files and File Chunks.
User Authentication Public Key
In Hive2Hive, the public key of a user's User Authentication Key Pair is referred to as User Authentication Public Key and is stored privately in the User Profile. This key is provided to peers that store data objects of a user to guarantee the authentication of data. It is used to verify signatures that have been signed with the associated User Authentication Private Key.
This key is used for the following:
User Authentication Private Key
In Hive2Hive, the private key of a user's User Authentication Key Pair is referred to as User Authentication Private Key. This key is used to sign data on the first put to guarantee the authentication of data. It is used to sign data objects that will be verified with the associated User Authentication Public Key.
This key is used for the following:
Shared Authentication Key Pair
By default, the User Authentication Key Pair is used to guarantee authentication. However, as soon as content in the DHT is about to be shared between users, this per-user key pair cannot be used anymore.
Instead, a new key pair, the Shared Authentication Key Pair, needs to be created and used for the authentication of the shared content. This applies for both read/write and read-only Access Permissions.
This key-pair is used for Data Authentication of:
- Shared Files:
- User Profile Tasks
Authentication of Data
Because put and get operations in a DHT are public, a major problem in P2P systems is the verification of authorized content access. In order to avoid unconscious (e.g., selection of an already used key) and conscious (e.g., manipulation attacks) network content modifications, such as overwrites or deletes, every accessor's modification permission has to be verified. Hive2Hive uses a mechanism that is referred to as Content Protection and is provided by the underlying TomP2P library.
This mechanism allows a user to sign data objects with her User Authentication Private Key when they are put to the DHT the first time. The next time any user tries to modify a data object, the correct User Authentication Public Key must be provided. Thus, only users owning the correct key are able to modify the corresponding content.
As long as the DHT location has not yet been allocated, it can be used.
Authentication of Messages
All messages that traverse the network are signed beforehand. The signature is done using the User Authentication Private Key of the sending user. The receiver verifies the authenticity of the message with the aid of the senders User Authentication Public Key, which can easily be fetched from the network. Thus, the origin of the message can be verified.
This mechanism does only apply for Notifications.