...
Sealing and signing objects is the preferred mechanism to secure data when
- Serializing serializing or transporting sensitive data
- A a secure communication channel such as SSL is absent or is too costly for limited transactions
- Sensitive sensitive data must persist over an extended period of time (for example, on a hard drive)
Avoid using home-brewed cryptographic algorithms; such algorithms almost certainly introduce unnecessary vulnerabilities. Applications that apply home-brewed "cryptography" in the readObject() and writeObject() methods are prime examples of anti-patternsantipatterns.
This rule applies to the intentional serialization of sensitive information. Rule SER03-J. Do not serialize unencrypted, sensitive data is meant to prevent the unintentional serialization of sensitive information.
...
| Code Block | ||
|---|---|---|
| ||
public static void main(String[] args)
throws IOException, GeneralSecurityException, ClassNotFoundException {
// Build map
SerializableMap<String, Integer> map = buildMap();
// Generate sealing key & seal map
KeyGenerator generator;
generator = KeyGenerator.getInstance("AES");
generator.init(new SecureRandom());
Key key = generator.generateKey();
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.ENCRYPT_MODE, key);
SealedObject sealedMap = new SealedObject(map, cipher);
// Serialize map
ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("data"));
out.writeObject(sealedMap);
out.close();
// Deserialize map
ObjectInputStream in = new ObjectInputStream(new FileInputStream("data"));
sealedMap = (SealedObject) in.readObject();
in.close();
// Unseal map
cipher = Cipher.getInstance("AES");
cipher.init(Cipher.DECRYPT_MODE, key);
map = (SerializableMap<String, Integer>) sealedMap.getObject(cipher);
// Inspect map
InspectMap(map);
}
|
Noncompliant Code Example (Seal
...
Then Sign)
This noncompliant code example uses the java.security.SignedObject class to sign an object, when the integrity of the object is to be ensured. The two new arguments passed in to the SignedObject() method to sign the object are Signature and a private key derived from a KeyPair object. To verify the signature, a PublicKey as well as a Signature argument is passed to the SignedObject.verify() method.
| Wiki Markup |
|---|
This noncompliant code example signs the object as well as seals it. According to Abadi and Needham \[[Abadi 1996|AA. Bibliography#Abadi 96]\], |
When a principal signs material that has already been encrypted, it should not be inferred that the principal knows the content of the message. On the other hand, it is proper to infer that the principal that signs a message and then encrypts it for privacy knows the content of the message.
| Wiki Markup |
|---|
The rationale is that any malicious party can intercept the originally signed encrypted message from the originator, strip the signature, and add its own signature to the encrypted message. Both the malicious party, and the receiver have no information about the contents of the original message as it is encrypted and then signed (it can only be decrypted after verifying the signature). The receiver has no way of confirming the sender's identity unless the legitimate sender's public key is obtained over a secure channel. One of the three CCITT X.509 standard protocols was susceptible to such an attack \[[CCITT 1988|AA. Bibliography#CCITT 88]\]. |
Because the signing occurs after the sealing, it cannot be assumed that the signer is the true originator of the object.
| Code Block | ||
|---|---|---|
| ||
public static void main(String[] args)
throws IOException, GeneralSecurityException, ClassNotFoundException {
// Build map
SerializableMap<String, Integer> map = buildMap();
// Generate sealing key & seal map
KeyGenerator generator;
generator = KeyGenerator.getInstance("AES");
generator.init(new SecureRandom());
Key key = generator.generateKey();
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.ENCRYPT_MODE, key);
SealedObject sealedMap = new SealedObject(map, cipher);
// Generate signing public/private key pair & sign map
KeyPairGenerator kpg = KeyPairGenerator.getInstance("DSA");
KeyPair kp = kpg.generateKeyPair();
Signature sig = Signature.getInstance("SHA1withDSA");
SignedObject signedMap = new SignedObject(sealedMap, kp.getPrivate(), sig);
// Serialize map
ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("data"));
out.writeObject(signedMap);
out.close();
// Deserialize map
ObjectInputStream in = new ObjectInputStream(new FileInputStream("data"));
signedMap = (SignedObject) in.readObject();
in.close();
// Unsign map
if (!signedMap.verify(kp.getPublic(), sig)) {
throw new GeneralSecurityException("Map failed verification");
}
sealedMap = (SealedObject) signedMap.getObject();
// Unseal map
cipher = Cipher.getInstance("AES");
cipher.init(Cipher.DECRYPT_MODE, key);
map = (SerializableMap<String, Integer>) sealedMap.getObject(cipher);
// Inspect map
InspectMap(map);
}
|
Compliant Solution (Sign
...
Then Seal)
This compliant solution correctly signs the object before sealing it. This provides a guarantee of authenticity to the object, in addition to protection from man-in-the-middle attacks.
...
SER02-EX1: Signing and sealing is only required for objects that must cross a trust boundary. Objects that never leave the trust boundary need not be signed or sealed. For instance, if an entire network is contained within a trust boundary, then objects that never leave this that network need not be signed or sealed.
Risk Assessment
Failure to sign and then seal objects during transit can lead to loss of object integrity or confidentiality.
...
Related Guidelines
CWE ID -319, "Cleartext Transmission of Sensitive Information" |
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="429adad3680867ac-5b2c5a70-42374c73-80699888-e51c070d94c155055dcb5a51"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API 06]] |
| ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="c8f17952ea177be5-145c0e29-46bc4e45-89aea2e4-d2076f967f5f452a2865f5e6"><ac:plain-text-body><![CDATA[ | [[Gong 2003 | AA. Bibliography#Gong 03]] | 9.10 Sealing Objects | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="59146ce6e5cb1400-864853ab-459f4e93-b103ac11-670066f6dba3b41554a660fa"><ac:plain-text-body><![CDATA[ | [[Harold 1999 | AA. Bibliography#Harold 99]] | Chapter 11: Object Serialization, Sealed Objects | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="6477b6bf3dd12a73-5f1fac49-4a83483c-be408578-5cea0aa81caef4b56e550935"><ac:plain-text-body><![CDATA[ | [[Neward 2004 | AA. Bibliography#Neward 04]] | Item 64: Use SignedObject to provide integrity of Serialized objects | ]]></ac:plain-text-body></ac:structured-macro> |
| Item 65: Use SealedObject to provide confidentiality of Serializable objects | |||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="4ce251a2efda7bba-45afe8ac-486943c4-99f99c7c-b1c669ba5924e474b531ca47"><ac:plain-text-body><![CDATA[ | [[Steel 2005 | AA. Bibliography#Steel 05]] | Chapter 10: Securing the Business Tier, Obfuscated Transfer Object | ]]></ac:plain-text-body></ac:structured-macro> |
...