Lowlevel stateless handing of reader transactions

[alonbl]

Stateless mode is very important as without this we have security issue as any application can use already authenticated session.

To solve this we can lock the reader for single application, but this is not a valid solution for many installations.

Stateless means that every transaction starts fresh:

• Begin transaction
• Select the DF and/or EF or key that we need to work with, even if it was previously selected !! we assume that another application may have send its own commands or even reset the card before the transaction so we take no assumption on the card state (e.g. what is the selected DF/EF, a PIN is verified etc.)
• verify the PIN (we cache the PIN in C_Login and are using the cached PIN for that).
• Send the card commands we need for that transaction
• Clear the PIN (un-verify it)
• End the transaction.

Working stateless will enable to simplify much of the readers code and also remove some of the PKCS#11 complexity.

Although PINPAD readers solves one security issue (Never expose your passphrase to the OS), it introduces a security issue if reader is not locked as the authenticated card can be used.

For PINPAD users we should continue to support reader locking.

There are some vendors who implement an authentication cookie, so that after PINPAD authentication the authentication cookie may be used to access the card later on, this is the best solution, but needs proprietary support.

[martin]

IMHO from security POV the card itself should enforce (and eID cards often do that) required authentication mechanisms and the fact that a card is usable by others in authenticated state is not a security issue. Authentication keys can be accessed by all applications once you have authenticated yourself once, but digital signature keys require a PIN entry each and every time you want to operate with that key - that is to sign a document (user_consent in code).

But for proper multiprocess access this change is necessary indeed.