Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Wiki Markup
It is imperative that sensitive data should be protected from eavesdropping and malicious tampering during transit. An Obfuscated Transfer Object \[[Steel 05|AA. Java References#Steel 05]\] can be used to encrypt data in exchanges that involve multiple business tiers or end user systems. Obfuscation can be achieved largely, by encrypting the sensitive object (sealing). This design pattern can further be supplemented to provide signature capabilities for guaranteeing object integrity.   

Signing and sealing objects takes preference over other similar measures is the preferred mechanism to secure data when:

  • The data is sensitive but its serialization or transportation is necessary
  • A secure communication channel such as SSL is absent or is a costly operation for a short interactionalternative for limited transactions
  • Some sensitive data needs to persist over an extended period of time (for example, on an external hard drive)
  • Implementing custom home-brewed cryptographic algorithms such as in the readObject and writeObject methods can leave the application exposed to security holes. It is advisable to not reinvent the broken wheel.vulnerable

Noncompliant Code Example

The This noncompliant code in this noncompliant example is capable of being serialized and transferred across different business tiers. Unfortunately, there are no safeguards against byte stream manipulation attacks while the binary data is in transit. Likewise, anyone can reverse engineer the stream data from its hexadecimal notation to unroll unravel the HashMap containing sensitive social security numbers.

...

Code Block
bgColor#ccccff
class SignSealUtility implements Serializable {
  final long serialVersionUID = 2648720192864531932L;
  private HashMap ssnMap;
  private SealedObject sealedSsnMap;
  private SignedObject signedSsnMap;
  
  public SignSealUtility() {
    ssnMap = new HashMap();
  }

  public void seal(Cipher cipher) throws Exception {
    sealedSsnMap = new SealedObject(ssnMap, cipher);
    // Now set the Map to null so that original data does not remain in cleartext
    ssnMap = null; 
  }

  public void unseal(Cipher cipher) throws Exception {
    ssnMap = (HashMap)sealedSsnMap.getObject(cipher);
  }
  
  public void sign(Signature sig, PrivateKey key) throws Exception {
    signedSsnMap = new SignedObject(ssnMap, key, sig);
    ssnMap = null;
  }

  public void unsign(Signature sig, PublicKey key) throws Exception {
    if(signedSsnMap.verify(key, sig)) {
      ssnMap = (HashMap)signedSsnMap.getObject();
    }
  }

  public Object getdata(Object key) throws Exception {
    return ssnMap.get(key);
  }
 
  public void setData(Object key, Object data) throws Exception {
    ssnMap.put(key, data);
  }
}

Note that the compliant solution throws a general Exception to limit the minutest of the information leaks that relate to the cryptographic implementation. Finally, one should refrain from signing encrypted (sealed) data. (See SEC32-J. Create and sign a SignedObject before creating a SealedObject)

...