9

While revising my CAdES library I encountered some "sealing issue" in digital signatures.

The Win SDK signtool.exe has a /seal parameter which produces 1 authenticated attribute in the signature "Intent to Seal" and one unauthenticated attribute "Sealing Signature" in the signed file.

I 've also seen that in PDF files. Couldn't find more online on it.

My questions are:

  1. What is the purpose of "sealing" vs simply signing a message?

  2. What are the OIDs associated with them? What are the relative RFCs?

  3. Is it simply a matter of adding 2 attributes in the PKCS#7 or is there another issue I must take into account?

  4. Is there a difference when timestamping a "sealed" message?

Patriot
  • 3,162
  • 3
  • 20
  • 66
Michael Chourdakis
  • 191
  • 1
  • 9

2 Answers2

3

Cryptographic sealing is the application of asymmetric cryptography to encrypt a session key so that it cannot be used-- until it is decided to remove the seal and use the key. It is a protection mechanism. See this description from Oracle:

Sealing the symmetric key involves creating a sealed object that uses an asymmetric cipher to seal (encrypt) the session key. The RSA asymmetric algorithm cannot be used because it has the size restrictions described in the next section, and the sealing process makes the session key too large to use with the RSA algorithm.

The idea of cryptographic sealing has been around for a long time. A paper from 1981, Cryptographic Sealing for Information Secrecy and Authentication., by David K. Gifford, goes into interesting detail about it:

A new protection mechanism is described that provides general primitives for protection and authentication. The mechanism is based on the idea of sealing an object with a key. Sealed objects are self-authenticating, and in the absence of an appropriate set of keys, only provide information about the size of their contents. New keys can be freely created at any time, and keys can also be derived from existing keys with operators that include Key-And and Key-Or. This flexibility allows the protection mechanism to implement common protection mechanisms such as capabilities, access control lists, and information flow control. The mechanism is enforced with a synthesis of conventional cryptography, public-key cryptography, and a threshold scheme.

So, the purpose of sealing is very different from that of signing. Sealing prevents use of a session key. I have been unable to find any RFCs that deal with sealing. Nor have I found any applicable OIDs. The timestamping involved in sealing, as far as the encryption process goes, will be the same as normal, as far as I can see. RFC 5652 (Cryptographic Message Syntax) does not specifically mention cryptographic sealing.

Community
  • 1
Patriot
  • 3,162
  • 3
  • 20
  • 66
1

Seems like a lot of bureaucratic-speak for something very simple.

This so-called sealing is identical to NaCl's sealed_boxes even if the intent seems to differ. Same algorithms. So you can look there for implementation.

You basically perform an ephemeral "handshake" (Diffie–Hellman) and delete the ephemeral private key afterwards, destroying key information pertaining to the handshake which just occurred. If the result of the handshake was used as a symmetric cipher for some data, that data is now encrypted by a key no one knows and only someone in possession of the private key to the other party in the handshake can recreate it - provided he is given the ephemeral public key which was generated and appended to the now encrypted data.

It differs from ordinary signing by being secret, the message itself can only be read by the intended recipient. Signing can be done in addition if required.

For an example of real world use, there is ransomware. They encrypt your files and seal the encryption key. After you pay them and give them the sealed key they give you (or their software) the unsealed key which then decrypts your files. Reverse engineering the malware will not get you the key used to encrypt the files, since it was destroyed.