com.ibm.opencard.access
Class MFCSecureAccessor
java.lang.Object
|
+--com.ibm.opencard.access.MFCCardAccessor
|
+--com.ibm.opencard.access.MFCSecureAccessor
- public class MFCSecureAccessor
- extends MFCCardAccessor
A card accessor that supports secure messaging and authentication.
This accessor extends the standard card accessor by capabilities to
satisfy access conditions involving AUT, PRO, and ENC. In order to
do so, it has to use cryptographic algorithms that are provided by
applications as implementations of MFCCredential.
Cryptographic functionality is subject to US export restrictions.
The government requests that exportable code must not provide
obvious hooks for adding crypto functionality. Therefore,
the functionality provided by this class is not included in the
base class, although it does not actually contain or directly use
any cryptography. This class is subject to US export regulations.
- Version:
- $Id: MFCSecureAccessor.java,v 1.1 1999/12/02 16:06:01 damke Exp $
| Methods inherited from class java.lang.Object |
clone,
equals,
finalize,
getClass,
hashCode,
notify,
notifyAll,
toString,
wait,
wait,
wait |
helper_AUT
protected MFCAuthenticator helper_AUT
- This helper will take care of external authentication.
helper_PRO
protected MFCProtector helper_PRO
- This helper will take care of message protection.
helper_ENC
protected MFCEncryptor helper_ENC
- This helper will take care of message encryption and decryption.
MFCSecureAccessor
public MFCSecureAccessor(MFCCHVProvider chverifier,
MFCAuthenticator authentor,
MFCProtector protector,
MFCEncryptor encryptor)
- Creates an accessor that supports secure messaging and authentication.
- Parameters:
chverifier - the helper for Card Holder Verificationauthentor - the helper for external Authenticationprotector - the helper for Protection by MACencryptor - the helper for Encryption and Decryption
execCommand
public ResponseAPDU execCommand(MFCCommandAPDU command,
MFCAccessConditions access)
throws CardServiceInabilityException,
CardServiceInvalidCredentialException,
CardServiceUnexpectedResponseException,
CardTerminalException
- Exchange APDUs with the smartcard.
This method is invoked by the card channel. The channel ID is already
encoded in the command APDU, so only the accessor will have to change
it by now. If the access conditions specify so, the accessor may have
to authenticate the application, to compute a MAC on the command, and
to encrypt it. The accessor may have to exchange further APDUs with
the smartcard in order to do so, for example to get a challenge random
number. Card holder verification may also be required. Of course, it
may be impossible to satisfy the access conditions.
After all other APDUs required to satisfy the access conditions have
been passed, the argument APDU is sent to the smartcard. Depending on
the access conditions, some postprocessing may be necessary, for example
to check the response's MAC, or to decrypt it. This will also be done
here, before the response is returned to the caller.
This method requires the APDU to be of class MFCCommandAPDU.
This class provides additional information specifying whether the
command itself, the expected response, or both are subject to secure
messaging operations.
The current implementation uses an optimistic approach.
It assumes that CHV and external authentication, if required,
have been performed before. If access is denied, they are performed
and the command is retried. There are two worst cases that may happen:
- CHV and authentication are both required, and CHV or both are
missing. The command will fail twice, since the first retry is
done after authentication and before CHV. If the authentication
has been performed before, there will be an overhead of three
useless commands.
- CHV and protection are both required, and CHV is missing. If
protection is needed both for the command and the response,
the failed command execution will have been preceeded by two
other commands, in order to exchange two random numbers with the
smartcard. Again, there is an overhead of three useless commands.
Note that encryption is similiar to protection, the case is identical.
The standard case is that the first command that requires CHV or
authentication will fail, while following commands execute without
overhead. If the overhead of the standard case, or the worst case
if it occurs, is not acceptable, CHV and authentication should be
performed explicitly.
- Parameters:
command - the APDU to send to the smartcardaccess - the access conditions for the command in the APDU- Returns:
- the response APDU obtained from the smartcard
- Throws:
- CardServiceInabilityException - The access conditions could not be satisfied.
- CardServiceInvalidCredentialException - The credentials provided were incorrect.
- CardServiceUnexpectedResponseException - A helper failed to interpret the smartcard's response.
- CardTerminalException - The terminal encountered an error.
- Overrides:
- execCommand in class MFCCardAccessor
sendCommandAPDU
protected final ResponseAPDU sendCommandAPDU(MFCCommandAPDU command,
MFCAccessConditions access)
throws CardServiceInabilityException,
CardServiceUnexpectedResponseException,
CardTerminalException
- Perform protection and encryption before sending a command.
These two access conditions are defined per command. If an access
fails due to missing authentication or CHV, both have to be done
again. Of course they are only performed if required by the access
conditions. If the command argument does get changed, the change is
idempotent. In any case, the command is available for retry.
- Parameters:
command - the APDU to send to the smartcardaccess - the access conditions to satisfy- Returns:
- the APDU received from the smartcard
- Throws:
- CardServiceInabilityException - Secure Messaging is required, but not supported.
- CardServiceUnexpectedResponseException - A helper failed to interpret the smartcard's response.
- CardTerminalException - The terminal encountered a problem.
|
