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.
Security
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.
Flexibility
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’.