-
Notifications
You must be signed in to change notification settings - Fork 0
Security Modules
The following diagram shows the architecture of the security module framework.
The interface to a security module contains a minimal set of low level security primitives that can be used by a digital notary to implement its interface. The functions include the following:
-
generateKeys()
- This function generates a new public-private key pair and returns the public key. -
rotateKeys()
- This function replaces the existing public-private key pair with a new key pair. It saves a copy of the old private key so that it can be used one more time to sign the new public certificate. -
eraseKeys()
- This function erases all keys from the module. -
digestBytes(bytes)
- This function returns a digital digest of the specified bytes. -
signBytes(bytes)
- This function returns a digital signature of the specified bytes, created using the private key (or the old private key if one exists, and then deletes the old private key). -
validSignature(aPublicKey, signature, bytes)
- This function determines whether or not the specified digital signature on the specified bytes is authentic according to the specified public key.
Over time, the version of the security protocol used by the security modules will likely change due to security issues being addressed in specific algorithms or as larger key sizes become necessary. Each security module implements one specific version of the security protocol.
The notary API supports the ability to add new versions of the protocol by adding new versions of the security modules, while still handling public certificate based requests that depend on earlier versions of the protocol. However, all private notary key based requests must use the latest version of the protocol to enforce maximum security compliance.
The current version (v2) of the notary protocol uses the following algorithms:
[
$digest: "sha512"
$signature: "ed25519"
]
There are no existing documents that were notarized using previous versions of the notary protocol so they are no longer supported.
An implementation of the security module functions is provided by two types of security module:
This module is implemented as a software library and provides all of the same security functions as the HSM including key management. Since it is in a software library, it is vulnerable to attack and should only be used on a physically secure server, or on a client device for testing purposes only.
This module implements all of the security functions in a separate, tamper-proof hardware device. The private notary key is generated on this device and never leaves it. To access it, a software library that acts as a proxy to the HSM implements the security module interface but delegates all actual security processing to the HSM via an "air gap".