In our IRMA project we develop a platform to support attribute based credentials (ABC) on a smart card. We believe the IRMA scheme is more secure and more flexible than the attestation based approach (as used by the German eID system, that use the placeholder name Mustermann on their sample cards). Below I will explain why.
In IRMA the smart card contains credentials. Credentials are secure containers of attributes issued and signed by attribute providers. An IRMA card holder can selective disclose attributes within the credentials on his card to a service provider. Without the signature on the credential, the service provider will not accept the attribute.
The attestation based approach relies on the tamper resistance of the smart card, on which the attributes are stored as plain strings without a signature. To prove ownership of an attribute, the card first proves it is genuine. The resulting secure session with the service provider is then used to transmit the necessary attributes to the service provider.
If the tamper resistance of a smart card is broken in the attestation based approach, arbitrary attribute values can be stored on the card (and subsequently be proven to a service provider). Smart cards with attribute based credentials do not run this risk, because the credentials containing these attributes are signed by the attribute provider whose key is not stored on the card. Changes to attributes will therefore be detected, and the only thing the attacker can do is create a clone of the card (with the same attributes). This difference is significant as hardware based attacks (like side channel analysis) are much more effective (and much harder to prevent) than cryptographic attacks.
Moreover, in its most basic form the attestation based approach assumes there is only a single attribute provider responsible for issuing all attributes on the card. This is clearly too limiting. Because the attributes carry no signature, somehow write access to the smart card must be restricted and separated for the different attribute providers (or else they could issue each others attributes...). One approach is to assign fixed slots (so called data groups) to a specific attribute provider to contain a predetermined attribute, and enforce controlled write access to these slots. This approach could be followed by the German eID system that is based on fixed data groups, but it is still not very flexible. You need to reserve space on the smart card for all possible attributes a user could have, instead of the ones he actually has. The system will quickly run out of available slots as smart cards have only limited memory.
To increase flexibility we have to abandon fixed data groups and instead use a list of attribute tag and value pairs. Attribute providers can than be restricted to update the list only for specific attribute tags. Or one could switch to attribute based credentials, and have the additional layer of security 'for free'.
[…] a previous blog post I discussed the difference in security and flexibility between attribute based credentials (used in our IRMA project) and the German eID system. Now I […]
I’m confused… I thought the nPA follows (and exceeds) the ICAO LDS spec, including passive authentication (i.e. signing of the datagroup contents). Am I wrong?
Passive authentication only protects the data for the official passport (biometric) application and the public key of the chip. The data groups of the non-official eID application are not signed (See BSI TR 03127-en, page 9). Signature verification of this data would also be slightly problematic because the eID application allows selective disclosure of certain attributes only (e.g. only revealing your name), so the signature should be over the hash of all hashes of all data groups, and the hashes of all non-revealed data groups would have to be sent to the verifier to check the signature.
Moreover, for age verification (where the card only answers whether the card holder was born prior to a specified date) this does not work at all.