The Layer security clients are designed to be easily embedded in business software, such as accounting or reporting packages. Hidden behind a simple integration interface are many powerful key management and cryptographic functions which ensure the highest levels of privacy and confidentiality.
Each end user will have a set of keys e.g. an AUSkey. Note that generally:
- The private key is protected by a keystore - usually a password protected file, but it can also be in a Hardware Security Module (HSM).
- The public key is protected by a certificate - by virtue that it is signed by a trusted Certificate Authority (CA).
When initially setup, the location of the keystore is configured (e.g. the AUSkey keystore). The keystore contains a user's credentials. A credential is the combination of a user's private key and their certificate. The user's private key is used to decrypt and to sign.
For efficiency, a certstore is used to store partner certificates. This allows certificates to be pre-configured (e.g. obtained out-of-band) or as an optimisation to avoid needing to obtain the partner certificate on every interaction. Partner certificates are used to encrypt and verify signatures.
Before encryption can occur, the sender needs to have a copy of the recipient's certificate. This is known as the "certificate distribution" problem.
Certificates may be obtained using a secure out-of-band exchange or a trusted certificate publisher. This is the case in e-Invoicing, where the partner certificate is obtained from a Digital Capability Provider (DCP).
Certificates can also be exchanged automatically if endpoints have been authenticated by a trusted third party:
Automated certificate exchange
In an automated certificate exchange, co-ordination messages may be sent as follows:
- Party "A" sends a signed co-ordination message the first time there is an interaction. The digital signature includes the Party A's certificate.
- Party "B" on receiving the request will store party A's certificate in its certstore and will send a signed co-ordination response, which includes Party B's certificate.
- Party "A" on receiving the reply will store party B's certificate in its certstore and now is able to encrypt and send the queued document.
End-to-End Encryption, Signing and Non-Repudiation
Documents (or any other file type) are sent using attachments. The documents are compressed, signed and encrypted. The recipient acknowledges the sent document.
Encryption, signing and non-repudiation
Attachments use a format called S/MIME (Secure/Multipurpose Internet Mail Extension) which in turn uses a format called CMS (Cryptographic Message Syntax) which is an international standard format for signing and encrypting data.
The sender compresses the document, signs it (using their private key) and encrypts it using the recipient's certificate (public key).
The recipient, decrypts the attachment (using their private key), verifies the signature (using the sender's certificate) and decompresses the document.
The recipient then sends a file acknowledge message back to the sender. This is like a read receipt and includes proof that the document was received e.g. the filename, its' size and a signed hash of the (decrypted) document. The file acknowledge is used for technical non-repudiation (other business information is required for legal non-repudiation). This helps prove the sender sent the document and that the recipient received it (and decrypted it).
Note the importance of end-to-end:
- Encryption - for confidentiality and privacy
- Digital signatures - for integrity and authenticity
- File acknowledge - for technical non-repudiation.