com.ibm.opencard.access
Interface MFCProtector
- All Known Implementing Classes:
- MFCSecureMessenger
- public abstract interface MFCProtector
The protector computes and verifies MACs over APDUs.
It is one of the helpers of MFCCardAccessor. A MAC (Message
Authentication Code) computation or verification involves a key. The
keys to use for protection have to be provided by the application.
Protection requires exchanging APDUs with the smartcard.
Since the commands for this purpose may be card-specific,
this is only an interface that has to be implemented by a
card-specific class.
Depending on the command, protection has to be performed for the
command itself, for the response, or for both. Protecting the command
requires asking the smartcard for a random number. Protecting the
response requires sending a random number to the card. If the response
is protected, it has to be processed by the protector, otherwise the
protector has to be invoked for the command only.
To simplify the interface and to decouple the accessor from the
intrinsics of the protector, protection is considered to be a
phase in the command transmission. The accessor will enter
this phase before sending the command to the card, and leave it
after the response has been received. Both is done by invoking a method
of this interface.
On entering the protection phase, the protector can determine whether
the command, the response, or both have to be protected. It will exchange
random numbers with the smartcard appropriately, and return a modified
command APDU including the MAC if necessary. If protection is required
for the response, the expected length for the response will have to be
adjusted in the command, too.
On leaving the protection phase, the protector will be supplied with the
smartcard's response APDU. It will check the MAC if this was considered
necessary on entering the phase. It can also reset it's internal state,
in which the random numbers and some key has probably been stored when the
protection phase was entered.
Within the phase, the only command sent to the smartcard (via the logical
channel used) will be the one returned by the entering method. Actually,
the protector could send that command itself, but sending commands is the
responsibility of the channel. Letting the protector send the command
would introduce a significant difference in the control flow, depending
on whether protection is required or not.
The phase can finish in a regular way or due to an error. If the response
from the smartcard does not indicate an error, it has to be processed to
check the MAC that may have been appended. If the response indicates an
error, or there was no response at all, the phase will be aborted. There
is no response processing on abortion, but the internal state of the
protector can be reset.
If an access condition like CHV or authentication has not been satisfied
when sending the command, the command will have to be retried. Time could
be saved in this case, since the key to be used will be the same. However,
the structure of MFCCardAccessor does not support this well, so
a re-issued command is dealt with as if it was another command. The time
for looking up the key is negligible compared to the card communication
time anyway.
- Version:
- $Id: MFCProtector.java,v 1.1 1999/12/02 16:06:01 damke Exp $
- See Also:
MFCCardAccessor
setCredentials
public void setCredentials(MFCCredentialSet credentials)
- Passes the accessor's credential set.
An accessor maintains a collection of credentials it can use.
Protection of a command sent to the smartcard requires knowledge
of a particular credential.
This method is invoked by MFCCardAccessor to provide the
credentials to this authenticator, which will pick the correct one when
protection has to be performed. It will be invoked only once, before
any of the other methods is invoked. Changes in the credential set must
be reflected by the protector immediately. The credential set will not
change within a protection phase.
- Parameters:
credentials - the set of available credentials- See Also:
MFCCredentialSet,
MFCCardAccessor.getCredentials()
enterProtection
public CommandAPDU enterProtection(MFCCardChannel channel,
MFCCommandAPDU command,
int number)
throws CardServiceUnexpectedResponseException,
CardTerminalException
- Prepares the execution of a protected command.
An invocation of this method enters a protection phase. The key to be
used will be looked up in the credential collection. The command is
analyzed to determine whether protection is required for the command,
the response, or both. Random numbers will be exchanged with the
smartcard appropriately. If required, a MAC is computed and appended
to the command.
- Parameters:
channel - how to contact the smartcardcommand - the APDU to compute a MAC fornumber - identifier of the protection key- Returns:
- the command APDU to send to the card, including a MAC if required
- Throws:
- CardServiceUnexpectedResponseException - A command sent to the smartcard failed.
- CardTerminalException - The terminal failed sending a command to the smartcard.
- See Also:
leaveProtection(opencard.core.terminal.ResponseAPDU),
abortProtection()
leaveProtection
public ResponseAPDU leaveProtection(ResponseAPDU response)
throws CardServiceUnexpectedResponseException,
CardServiceInvalidCredentialException
- Finishes the execution of a protected command.
An invocation of this method leaves a protection phase.
The smartcard reponse's MAC is checked, if necessary.
The internal state of the protector will be reset to prepare
for the next phase.
- Parameters:
response - the APDU received from the smartcard- Returns:
- the smartcard's response, without MAC
- Throws:
- CardServiceUnexpectedResponseException - The response to verify has a bad message format.
- CardServiceInvalidCredentialException - The response to verify is not authentic.
- See Also:
enterProtection(com.ibm.opencard.service.MFCCardChannel, com.ibm.opencard.service.MFCCommandAPDU, int)
abortProtection
public void abortProtection()
- Cancels the execution of a protected command.
This method is invoked if an error occured while the command was
executed. It is similiar to leaveProtection, except that
there is no response that may be processed.
- See Also:
enterProtection(com.ibm.opencard.service.MFCCardChannel, com.ibm.opencard.service.MFCCommandAPDU, int),
leaveProtection(opencard.core.terminal.ResponseAPDU)
|
