| Wiki Markup |
|---|
Sensitive data must be protected from eavesdropping and malicious tampering. An obfuscated transfer object \[[Steel 2005|AA. Bibliography#SteelReferences#Steel 05]\] that is strongly encrypted can protect data. This approach is known as _sealing_ the object. To guarantee object integrity, apply a digital signature to the sealed object. |
...
| Wiki Markup |
|---|
This noncompliant code example signs the object as well as seals it. According to Abadi and Needham \[[Abadi 1996|AA. Bibliography#AbadiReferences#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 |
|---|
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 be decrypted only 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 Internal Telegraph and Telephone Consultative Committee (CCITT) X.509 standard protocols was susceptible to such an attack \[[CCITT 1988|AA. Bibliography#CCITTReferences#CCITT 88]\]. |
Because the signing occurs after the sealing, it cannot be assumed that the signer is the true originator of the object.
...
| Wiki Markup |
|---|
*SER02-EX0:* A reasonable use for signing a sealed object is to certify the authenticity of a sealed object passed from elsewhere. This represents a commitment _about the sealed object itself_ rather than about its content \[[Abadi 1996|AA. Bibliography#AbadiReferences#Abadi 96]\]. |
SER02-EX1: Signing and sealing is required only for objects that must cross a trust boundary. Objects that never leave the trust boundary need not be signed or sealed. For instance, when an entire network is contained within a trust boundary, objects that never leave that network need not be signed or sealed.
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="6522ee130525c543-cf9e4e88-4867435e-99aeabd1-6705dc8129344f78c09fe62f"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API References#API 06]] |
| ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="e2c9d8962eeff9a2-6b46f6b4-47d2494e-a618a1d5-e388d9bd3e33afaa68d58112"><ac:plain-text-body><![CDATA[ | [[Gong 2003 | AA. Bibliography#Gong References#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="642e03440d95468f-a09ec5f0-4e064e5c-92c9bf6a-28e6b2a91427fa4dfdd5d980"><ac:plain-text-body><![CDATA[ | [[Harold 1999 | AA. Bibliography#Harold References#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="9086d1929f5ad3a9-7f0c1522-4e9b4280-b40ab7a9-e3a119f4b63b0c2b09d30fbe"><ac:plain-text-body><![CDATA[ | [[Neward 2004 | AA. Bibliography#Neward References#Neward 04]] | Item 64, Use | ]]></ac:plain-text-body></ac:structured-macro> |
| Item 65, Use | |||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="b67f2b367e5d24d6-30428348-4e5246db-9797b149-a61d6bb5fb9bb9a07069a2f5"><ac:plain-text-body><![CDATA[ | [[Steel 2005 | AA. Bibliography#Steel References#Steel 05]] | Chapter 10, Securing the Business Tier, Obfuscated Transfer Object | ]]></ac:plain-text-body></ac:structured-macro> |
...