96
L. Hanzlik and M. Kutyłowski
• A runs the verification process,
• after a positive answer from A the terminal T establishes a connection with J .
Unfortunately, this approach has limited usability:
• it does not work for the offline eID–reader scenario,
• a reader must run all protocols notified in the EU,
• when the authentication service learns that the eID is active at some place. for
some protocols the online authentication service can learn the session key and be
able to eavesdrop on the communication.
Sometimes cooperation between eID providers is limited, e.g., due to different
approaches to personal data protection (such as for the EU versus the US).
User–eID interaction While declaratively users pay attention to their own security,
the standard behavior is to trade security for convenience. A good eID system should
take this into account. On the other hand, a user has to be given a minimal level of
control over their eID. This should include in particular the possibility to:
• temporarily block their own eID,
• get a record of their former activities.
In existing systems, there are limited possibilities to suspend or invalidate an eID
based on inserting entries into a central database. This is not enough to prevent
lunchtime attacks, where an eID is seized by an adversary for a short time. To keep
track of eID activity one could deploy for instance a transaction counter or some
more sophisticated solution (see, e.g., [349].
5.6 Future Directions
Composability The main goal of eID protocol designers should be composability.
That is, given a limited number of cryptographic procedures it should be possible
to implement all required functionalities and even leave room for new applications.
This approach not only ensures that an eID can be created with cheaper hardware
(i.e., less code means less memory used), but also makes it easier to create and reuse
a formal security analysis.
Extensions The protocol stack implemented in an eID should allow extensions. In
particular, it should be possible to build new security features on top of the existing
stack.
Simple Protocol Changes If a security flaw is found, the protocol designers should
focus on simple fixes that make only small changes to the existing protocols. This
would not only simplify the security analysis of the new protocol but also speed
L. Hanzlik and M. Kutyłowski
• A runs the verification process,
• after a positive answer from A the terminal T establishes a connection with J .
Unfortunately, this approach has limited usability:
• it does not work for the offline eID–reader scenario,
• a reader must run all protocols notified in the EU,
• when the authentication service learns that the eID is active at some place. for
some protocols the online authentication service can learn the session key and be
able to eavesdrop on the communication.
Sometimes cooperation between eID providers is limited, e.g., due to different
approaches to personal data protection (such as for the EU versus the US).
User–eID interaction While declaratively users pay attention to their own security,
the standard behavior is to trade security for convenience. A good eID system should
take this into account. On the other hand, a user has to be given a minimal level of
control over their eID. This should include in particular the possibility to:
• temporarily block their own eID,
• get a record of their former activities.
In existing systems, there are limited possibilities to suspend or invalidate an eID
based on inserting entries into a central database. This is not enough to prevent
lunchtime attacks, where an eID is seized by an adversary for a short time. To keep
track of eID activity one could deploy for instance a transaction counter or some
more sophisticated solution (see, e.g., [349].
5.6 Future Directions
Composability The main goal of eID protocol designers should be composability.
That is, given a limited number of cryptographic procedures it should be possible
to implement all required functionalities and even leave room for new applications.
This approach not only ensures that an eID can be created with cheaper hardware
(i.e., less code means less memory used), but also makes it easier to create and reuse
a formal security analysis.
Extensions The protocol stack implemented in an eID should allow extensions. In
particular, it should be possible to build new security features on top of the existing
stack.
Simple Protocol Changes If a security flaw is found, the protocol designers should
focus on simple fixes that make only small changes to the existing protocols. This
would not only simplify the security analysis of the new protocol but also speed