Skip to content

Selective encrypted transmission

Name

Selective encrypted transmission

Summary

An entity actively encrypts the necessary (sensitive) data elements before transmitting them over an uncontrolled communication channel to the intended recipient.

Parent

None

Problem

  • Ensure that the exchanged (sensitive) data does not leak to unauthorised entities.

Solution

The crux of this pattern is that the communicating entities themselves have to decide which transmitted elements to encrypt and actively do so before transmission. In other words, these entities directly interact with their cryptographic libraries in order to ensure only the necessary parts of the communication are encrypted.

This pattern thus instantiates the Encryption pattern where encryption happens on the sender side and decryption on the receiver side.

Roles

  • Sender (: Entity) wants to confidentially transmit one or more data elements to another entity
    • Sender <- Encryption.EntityA
  • Receiver (: Entity) wants to be able to decrypt confidentially transmitted data elements it receives from Sender
    • Receiver <- Encryption.EntityB
  • CryptographerS (: Cryptographic primitive) a cryptographic library through which the Sender can, at least, encrypt data elements
    • CryptographerS <- Encryption.Encryption provider
  • CryptographerR (: Cryptographic primitive) a cryptographic library through which the Receiver can, at least, decrypt received cipher texts
    • CryptographerS <- Encryption.Encryption provider

Note

The cryptographic libraries used by Sender and Receiver can differ from each other but must provide compatible cryptographic primitives in order for them to be able communicate. For example, they should both support the same cipher (configuration) to successfully encrypt and decrypt messages.

Actions

  • encrypt (: Action) a given plaintext d using the identified key and cipher configuration, if provided
  • decrypt (: Action) a given ciphertext {d}_k using the identified key and cipher configuration, if provided
  • action (: Action) the action the Sender requests from to the Receiver for which it provides the data element as argument (optional)

Note

Depending on the selected cryptographic libraries the encrypt as well as decrypt action may be refined to multiple calls to the library's API.

Data elements

  • d (: Data) plaintext data element that the Sender wants to send to the Receiver
    • d <- Encryption.plaintext
  • {d}_k (: Data) ciphertext corresponding to plaintext d encrypted with cryptographic key k
    • {d}_k <- Encryption.ciphertext
  • args (: Data) additional arguments that are transmitted as plaintexts (optional)
  • keyInfoS (: Data) information on the cryptographic key that should be used to encrypt the plaintext. This can, for example, be an identifier so that the CryptographerS knows which key to use or the cryptographic key itself.
    • Tags: Untampered[, Secret]
    • keyInfoS <- Encryption.keyInfo
  • configS (: Data) the necessary information for the CryptographerS to initialise the required encryption cipher. The exact (possible) values depend on the selected cryptographic library, some possible options are key length, mode, and block size.
    • Tags: Untampered
    • configS <- Encryption.config
  • keyInfoR (: Data) information on the cryptographic key that should be used to decrypt the ciphertext. This can, for example, be an identifier so that the CryptographerR knows which key to use or the cryptographic key itself.
    • Tags: Untampered[, Secret]
    • keyInfoR <- Encryption.keyInfo
  • configR (: Data) the necessary information for the CryptographerR to initialise the required decryption cipher. The exact (possible) values depend on the selected cryptographic library, some possible options are key length, mode, and block size.
    • Tags: Untampered
    • configR <- Encryption.config

Behaviour

Before the Sender and Receiver can successfully exchange ciphertexts they must agree on a cipher that is supported by their respective cryptographers.

  1. The Sender requests its CryptographerS to encrypt the plaintext message d, using the key specified by keyInfoS and, if provided, the cipher specified in configS.
  2. The CryptographerS performs the requested encryption and returns the ciphertext {d}_k to the Sender.
  3. The Sender transmits the ciphertext, possibly as part of an action request or along with other data, to the Receiver.
  4. The Receiver requests its CryptographerR to decrypt the received ciphertext {d}_k using the key specified in keyInfoR using the cipher configured in configR, if provided.
  5. The CryptographerR performs the decryption and returns the plaintext to the Receiver who can process it further.

Sending entity selectively encrypts before sending

Role considerations

Encryption role considerations

All role considerations of the instantiated Encryption pattern should also be followed.

Cipher negotiation (Sender, Receiver)

In order to be able to successfully communicate the Sender and Receiver need to (implicitly) agree on the used encryption cipher, this includes the encryption algorithm used, its exact configuration, and the cryptographic key(s) used. This negotiation can happen at different stages in the life cycle of the software entities at hand.

Configured negotiation

Sender and Receiver can be configured (at design time, during deployment, or at runtime) to use compatible encryption and decryption primitives. For example, the Sender could be configured during deployment to retrieve the Receiver's public key and use it to encrypt the message. The Receiver in turn will have to be configured to use its corresponding private key to decrypt the message received from Sender. Similarly, Sender and Receiver can both be configured with a shared symmetric key.

In any case, appropriate measures should be taken to ensure the integrity, and possibly the confidentiality, of the agreed upon cipher configuration at both the Sender and Receiver. An attacker should, for example, not be able to change the Sender's configuration such that the Sender retrieves a public key controlled by the attacker instead of that from the intended Receiver. In general, the integrity of the configuration should be ensured during transmission and while at rest. If the configuration also contains sensitive data, e.g. cryptographic keys, it should also be kept confidential.

Runtime negotiation

The Sender and Receiver can also negotiate a cipher at runtime, typically shortly before transmitting the encrypted message(s). In most cases this negotiation will be conducted over the same uncontrolled channel as the subsequent encrypted communication. In any case, Sender and Receiver should only use a standardised negotiation protocol that is provided by their respective cryptographic libraries. Under no circumstance should the Sender or Receiver use a custom, self-defined protocol or implement one themselves.

Any inputs that are required for the negotiation protocol should be adequately protected. For example, negotiation protocols often rely on public-key pairs to encrypt the negotiation messages exchanged between the participants. In this case, the Sender and Receiver should take appropriate measures to ensure the integrity of the public and private keys, as well as ensure that their private keys remain confidential. This includes measures with respect to (persistent) storage of these keys as well as their potential transmission when send to or retrieved from another entity.

Data considerations

Encryption data considerations

All data considerations of the instantiated Encryption pattern should be followed.

Implementations

None

References

Last update: February 7, 2022