RE: Attribute encryption

I have been following the arguments against attribute encryption.  So far, 
I think there are 3 arguments:

1. There is not a need to encrypt attribute data.
2. Encrypting attribute data adds complexity.
3. Encrypting attribute data has security issues.

I don't think that any of these reasons are grounds for excluding attribute 
encryption.

1. There is not a need to encrypt attribute data.

I have looked at a number of XML applications and vocabularies that are 
currently in use.
Attributes can and do contain sensitive information.  For example:

<Patient contagion-alert="blood" contagion-level="high" . . . . >
    <name>Jane Doe</name>
    <address> . . . . . .
</Patient>

The above patient record alerts practitioners that the patient has a highly 
contagious blood condition (possibly HIV).  The practitioners need to know 
this, but for patient privacy the billing department should not see this 
information.

2. Encrypting attribute data adds complexity.

As to the issue of complexity verses value; customers pay for applications 
to deal with complexity.  It is our bread and butter.  I agree that we want 
to keep standards and implementations as simple as possible.  But 
attributes exist and they contain data. We cannot tell a paying customer to 
redesign their legacy applications and XML vocabularies.  The task is to 
find simple and elegant ways of handling the encryption of attribute data.

3. Encrypting attribute data has security issues.

That is true.  But let's solve the problem rather than run away from 
it.  The problem with enumerated attributes and small attribute data 
lengths can be solved the same way as the problems with encrypting Elements 
or NodeList fragments.  See the "Open Issues" of  XML Encryption Syntax and 
Processing, Version 1.0, 15-December-2000 (text is copied below):

   5. It has been noted by Hal Finney, Steve Wiley, et al that encrypting 
XML raises concerns over attacks based on known plaintext as well as known 
length of the encrypted plaintext. This issue, in regards to encrypting 
enumerated attributes values, is one reason for not supporting 
attribute-value encryption. But, it remains an issue with Elements or 
NodeList fragments. Specifically, the attacker may know the XML schema for 
the encrypted data and the plaintext may consist primarily of element tags 
with short variable values of known length. For example:

<AccountInfo>
<AccountType>S</AccountType>
<AccountNumber>123456</AccountNumber>
</AccountInfo>

If the AccountType value is one character from a small know set, and the 
AccountNumber value is 6 digits, it is trivial to enumerate the possible 
plaintexts. Furthermore, the encrypted octet sequence length will typically 
be the plaintext size rounded up to the nearest multiple of the cipher 
block size. This may help in guessing the structure of the plaintext data 
even if some variability is possible. To address this, one could introduce 
required padding when encrypting Elements or NodeLists. Use of a prepended 
string of non-zero random bytes, followed by a zero byte, and then the 
plaintext to be encrypted similar to PKCS-1 v1.5 is one suggested approach. 
It needs to be determined if such padding should be defined by this 
specification and whether its use is mandatory or recommended.

Received on Wednesday, 10 January 2001 14:47:17 UTC