|CipherVersionFactory<CV extends CipherVersion>|
|CipherVersionGenerator<CV extends CipherVersion>|
This exception is the base runtime exception for the directory artifact
The refcodes-forwardsecrecy artifact provides a framework for easy encryption and decryption functionality with a high throughput. The design is strictly using separation of concerns regarding encryption functionality and decryption functionality.
This framework is designed to perform encryption and decryption on huge amounts of data. Therefore a symmetric cryptography approach (fast) is used for encryption and decryption purposes, being combined with an asymmetric cryptography approach (secure) for symmetric cipher exchange. Security is increased with the possibility of continuously changing the symmetric ciphers.
The forward secrecy cryptography infrastructure as discussed here is to handle persistent data. Using a pure asymmetric encryption approach would not reduce the security hot spot. Furthermore the disadvantage of an asymmetric cryptography approach comes for many small chunks of data to be processed; even when used in combination with a symmetric cryptography approach (similar to the HTTPS handshake):
Processing small chunks of data either directly with an asymmetric cryptography approach or combined with a symmetric cryptography approach with post processing of the symmetric cipher for that chunk with an asymmetric cryptography approach costs execution time for each data chunk processed respectively; which is to a great extend slower than processing using a symmetric approach. The assumption behind it might be that asymmetrically processing symmetric ciphers is less cost intensive than asymmetrically processing the data itself. With small chunks of data this assumption is not true. The vastly reduce execution time this framework processes the symmetric ciphers for the data chunks independent from the data chunks; separately handled by an asymmetric cryptography approach; also independent from the data chunks; preventing the costly execution time to process each data chunk with an asymmetric cryptography approach.
There are two common used types of refcodes-forwardsecrecy setup for your applications.
a) BASIC SETUP: The basic setup encrypts the symmetric ciphers of the encryption part with the public key of the decryption part. Any decrypting participant located in the decryption part must have access to the same private key in order to make use of the encrypted ciphers.
b) USUAL SETUP: The normal setup is similar to the basic setup with the addition that for using the ciphers on the decryption part, additional key pairs are required for each decryption participant located in the decryption part; each decrypting participant uses its own private key, a single private key must not be known by all decrypting participants.
Provider: A provider can be an encryption provider or a decryption provider and is being used by the business logic to encrypt or decrypt texts. The business logic must not know anything about ciphers or cipher versions. For encryption or decryption a symmetric encryption approach is used
Service: The service can be an encryption service or a decryption service managing ciphers or cipher versions exclusivity in-memory for the symmetric encryption approach. For exchanging cipher versions with a data store (file-system, repository) between the encryption and the decryption systems (encryption- and decryption servers), an asymmetric encryption approach may be used.
Server: A server can be an encryption server or a decryption server; responsible for securely storing (encryption server) or securely retrieving (decryption server) cipher versions. Hence a server is required for exchanging cipher versions between the data store (file-system, repository) and the according services; here an asymmetric encryption approach may be used for encrypting cipher versions (encryption server) and decrypting cipher versions (decryption server).
Actually the complete asymmetric cipher version exchange can be handled inside the services layer so that the servers must not know anything about private or public keys (BASIC SETUP). This has the shortcoming, that all decrypting services must have access to the same private key . It has the advantage, that the sever does not unveil any ciphers. Nevertheless a decryption wrapper can be implemented wrapping the decryption sever and adding additional key-pair support for cipher version exchange with the decryption services (NORMAL SETUP).
As we support encryption and decryption, the triple of provider, service and server exists for the encryption part as well as for the decryption part.
At a closer look, we see the following types participating in the refcodes-forwardsecrecy framework:
It is merely responsible for retrieving a currently valid cipher for encrypting data. The encryption provider does not expose the cipher though it might store it in clear text in-memory only (advanced implementations might encrypt the in-memory cipher). The (internally) retrieved cipher is requested from and provided by an encryption service (on the same machine) which takes care of providing (and creating) a cipher with a cipher UID as well as publishing the according cipher version (via the encryption server to the decryption server). As the encryption provider does not persist any data, an in-memory cipher version will only be used as long as the encryption provider is up-and-running. In case of a restart, a new cipher for encryption is requested from the encryption service. Also the encryption provider can be forced to (create and to) use a next valid cipher on demand.
The encryption service may make use of an encryption server persisting cipher versions per namespace. It could actually generate a dedicated cipher just once, so any unauthorized system having access to the ciphers gets a different cipher not used by any of the authorized participant. Never two participants will encrypt with the same cipher (taken the probability that two participants generate the same cipher is very low and nearly never to happen; in case it happens there is still no security risk). The key advantage is that if an intruder can also retrieve ciphers, those ciphers being retrieved are never used by other systems for encryption as a cipher version is bound to the requester.
To later determine which cipher to use when decrypting data, each cipher has a cipher UDI assigned to it (a cipher UID and cipher make up a cipher version). Encrypted data is prefixed with this cipher UID so later it is easy to determine which cipher is responsible for decryption. The cipher UID is assumed to be public as it's generation must be completely independent from the cipher itself. Unauthorized systems having access to the cipher UID cannot reverse calculate the cipher
There is not even a relation between cipher and cipher UID in terms if hash code. This means using brute force approaches with rainbow tables or whatsoever to reconstruct the cipher from the cipher UID is to fail.
Depending on the implementation, the encryption service makes use of a public key of an asymmetric encryption approach for encrypting the cipher versions; to be persisted by the encryption server.
Encrypting only the cipher is sufficient, the cipher UID can be stored in plain text; it securely can be assumed to be public. As said before, any intruder knowing the cipher UIDs does not weaken the forward secrecy cryptography infrastructure as knowing the cipher UIDs is only of use with the according ciphers; which cannot be calculated from the cipher UIDs.
Regarding the implementation of the encryption server, securely persisting can be done with the public key of an asymmetric encryption approach so that only the decryption service can get the plain text ciphers from the cipher versions. To avoid transmitting plain text cipher versions from the encryption service to the encryption server, the encryption service should already encrypt the cipher version with the according public key so that the encryption server always receives encrypted cipher versions.
The forward secrecy cryptography infrastructure supports encryption servers which only need to take care of persisting the cipher versions and retrieving them. Encryption and decryption can be done in the according service layers. E.g. the encryption service uses a public key to encrypt the cipher of a cipher versions and passes it to the encryption server just storing the cipher version without any additional encryption. A decryption service in turn requests the cipher versions with the encrypted ciphers from the decryption server and is decrypting the ciphers with the according private key. Another more complex approach is described regarding the decryption server.
By replacing the implementation of the encryption server, the way cipher versions are persisted can be changed easily.
Depending on the implementation, the decryption server might as well contain a number of public keys (for an asymmetric encryption approach) also assigned to the individual namespaces identifying the owners of the private keys with which it is secure to communicate.
The decryption server might access persisted cipher versions. Depending on the implementation, the cipher versions to be persisted must be encrypted with the decryption server's public key. An encryption service having this public key then can do secure persisting.
Requesting the cipher versions from the decryption server might then be done by authenticating that the requester is entitled to request the cipher versions by verifying the signature of a requester's message with the public keys by the decryption server and by encrypting the cipher versions with that according public key. The decryption server itself might use an asymmetric encryption approach to decrypt persisted cipher versions persisted by the encryption server (and being encrypted by the encryption service).
A decryption server's wrapper could be hooked on top the decryption server which uses the private key used for encrypting the ciphers by the encryption service to decrypt the ciphers and encrypts the ciphers again with a public key from a key pair of an according decryption service. The decryption service authenticates itself with a message and a message's signature generated from its according private key. The decryption server can validate the signature and use the trusted public key for encryption. By replacing the implementation of the decryption server, the way cipher versions are persisted can be changed easily.
The decryption service may make use of a decryption server managing the cipher versions per namespace.
Depending on the implementation, the decryption service has a private key for an asymmetric encryption approach whose public counterpart is used by the encryption service. This private key then is used to decrypt the ciphers form the retrieved cipher versions.
A decryption server's wrapper may be hooked on top of the decryption server containing public keys known as being trusted and the private key for decrypting ciphers being encrypted by the encryption service. When cipher versions are being requested by a decryption service from the wrapped decryption server, the decryption service authorizes itself by signing a message with a signature passed to the decryption server. In case the message's signature is verified by the decryption server with one of its trusted public keys, then the public key in question is used by the decryption server for encrypting the cipher versions being transmitted to the decryption service.
The decryption provider provides decrypting functionality as encrypted data must be decrypted again by another service or system. This system must now be able to retrieve all known ciphers versions (by a decryption service) for determining the correct cipher for decrypting encrypted text (as encrypted text is prefixed by the cipher UID identifying the cipher to use for decryption).
In case you provide your custom cipher version factory implementation, make sure the cipher version (sub-)type you return fits with the cipher version (sub-)type of your custom cipher version generator. A good approach is to make your custom cipher version generator make use your custom cipher version factory (see the default implementations of the cipher version generator and cipher version factory).
In case you provide your custom cipher version generator implementation, make sure the cipher version (sub-)type you return fits with the cipher version (sub-)type of your custom cipher version factory. A good approach is to make your custom cipher version generator make use your custom cipher version factory (see the default implementations of the cipher version generator and cipher version factory).
Copyright © 2016. All rights reserved.