Security
There are two main actors in this system 'Agency Node' which handles all the user's agents and their respective wallets and 'Enterprise Agent Node' which is a standalone agent representing an organization. These two actors handle their own internal security and also communicate with each other using a secure encrypted protocol.
Actors in a self-sovereign identity ecosystem may own or control many different types of data:
- encryption and signing keys
- payment keys
- link secrets
- PII about themselves or others
- credentials
- personal documents (e.g., last year's tax filing, journal, love letters)
- digital breadcrumbs (e.g., purchase history)
- photos and videos
- receipts
- health records
...and much more. Different subsets of data may be worthy of different protection efforts. The figure below represents the precedence of data from left to right.
Wallets are at the core of this system and are secured with high-level encryption. Wallets need very robust encryption. However, they must also be searchable, and the encryption must be equally strong regardless of which storage technology is used. We want to be able to hide data patterns in the encrypted data, such that an attacker cannot see common prefixes on keys, or common fragments of data in encrypted values. And we want to rotate the key that protects a wallet without having to re-encrypt all its content. This suggests that a trivial encryption scheme, where we pick a symmetric key and encrypt everything with it, is not adequate.
The wallet encryption takes following approach:
The 7 "column" keys are concatenated and encrypted with a wallet master key, then saved into the metadata of the wallet. This allows the master key to be rotated without re-encrypting all the items in the wallet.
All encryption is done using ChaCha20-Poly1305, with HMAC-SHA256. This is a solid, secure encryption algorithm, well tested and widely supported. The world outside a wallet interfaces with the wallet through a public interface provided by indy-sdk, and implemented only once. This is the block labeled encryption, query (wallet core) in the diagram. The implementation in this layer guarantees proper encryption and secret-handling. It also provides some query features. Records (items) to be stored in a wallet are referenced by a public handle if they are secrets. This public handle might be a public key in a key pair, for example. Records that are not secrets can be returned directly across the API boundary.
The way the individual fields are encrypted is shown in the following diagram. Here, data is shown as if stored in a relational database with tables. Wallet storage may or may not use tables, but regardless of how the storage distributes and divides the data, the logical relationships and the encryption shown in the diagram apply.
The security of the agency node and enterprise agent node can be classified into two modules internal and external. Where internal security manages secrets storage and secure accessibility to the node, external security deals with all incoming and outgoing requests and their encryption. Section 'Security Architecture' below illustrates the system's security protocols implementation and interaction.
Internal security protocols responsibly manage wallet encryption as mentioned in the 'Wallet Security' section. A 256-bit Rivest–Shamir–Adleman (RSA) key pair is generated on the provision of both agency node and enterprise agent node. These key pairs are used at various steps in internal security protocols. Semi-sensitive data such as connections information, pending credential requests, pending proof offers and registered services are stored as unencrypted data on the node's filesystem and rely on the integrity of node accessibility which is covered by external security protocols. For the agency node upon login, the users with registered wallets are issued a 256-bit RSA signed JSON Web Token (JWT) with a validity of 12 hours. Users can utilize this JWT to make API calls and communicate with the agency node.
For the enterprise agent node, the scenario is a bit different as the node hosts one agent and its respective wallet. The one known agent of type enterprise should have complete access to its wallet. A default username and password is created upon the provision of the agent. This password can be later updated by the enterprise agent. The password is encrypted with the node's private key using 256-bit RSA encryption and stored in the local database. On login, an enterprise agent user with a valid username and password is provided with a 256-bit RSA signed JSON Web Token (JWT) with a validity of 12 hours. Enterprise agent user can utilize this JWT to make API calls and communicate with the enterprise agent node.
External security protocols are responsible for managing the node's secure interaction and encrypted communications. This system is designed to work in a private network with no direct SSH accessibility. This means that only administrators who provision the network and deploy the decentralized applications can access the nodes of the network. Moreover, all the traffic over the agency node and enterprise agent node from and to the outside world happens over the Transport Layer Security (TLS) protocol which guarantees the security of server requests and their respective responses.
However, the communication between the agency node and enterprise agent node is secured using private encryption protocol rather than the TLS protocol. One of the possible reason behind this is that the indy ledger is yet not capable of creating an association of public DID with a URL endpoint. Currently, all public DID's are associated with an IP address followed by a port number and not complying with the format of 'IP_ADDRESS:PORT' invalidates the ledger request. Which makes it difficult to impose a TLS protocol over the communication channel.
The private encryption protocol used for communication between the agency node and the enterprise agent node is based on ed25519 encryption. ed25519 Edwards-curve Digital Signature Algorithm (EdDSA) is a digital signature scheme using a variant of Schnorr signature based on Twisted Edwards curves. It is designed to be faster than existing digital signature schemes without sacrificing security. ed25519 Authenticated-encryption scheme and Anonymous-encryption scheme are two different types of schemes that are used in this system to protect the integrity and identity of the user.
- Anonymous-encryption scheme
Sealed boxes are designed to anonymously send messages to a Recipient given its public key. Only the Recipient can decrypt these messages, using its private key. While the Recipient can verify the integrity of the message, it cannot verify the identity of the Sender.
- Authenticated-encryption scheme
Sender can encrypt a confidential message specifically for Recipient, using Sender's public key. Using Recipient's public key, Sender can compute a shared secret key. Using Sender's public key and his secret key, Recipient can compute the exact same shared secret key. That shared secret key can be used to verify that the encrypted message was not tampered with, before eventually decrypting it. Recipient only needs Sender's public key, the nonce and the ciphertext to peform decryption. The nonce doesn't have to be confidential.
