Limitations Regarding Certificate
Handling on Smart Cards
Konstantinos Rantos?
Industrial Informatics Department,
Technological Educational Institute of Kavala,
Ag.Loukas, Kavala, GR-65404, Greece
kostas@rantos.com
Abstract. A public-key infrastructure (PKI) typically requires use of
tamper-proof devices that can perform crypto computations and store
highly sensitive data like private keys. Smart cards are the low cost devices that satisfy these requirements and, as a result, they can boost the
wide deployment of a PKI. Yet certain limitations exist regarding the
handling of certificates, one of the supporting mechanisms of an infrastructure, from these limited capabilities devices. This paper addresses
these issues and shows why smart cards are not the panacea to public
key technology deployment.
1
Introduction
A smart card is a secure device whose tamper resistance renders it very attractive
for cryptographic computations and storage of sensitive data. As such, they are
deployed in major security critical applications in the financial sector, including
banking and electronic commerce, as well as for physical or logical access control.
Smart cards are usually the choice of applications that utilise public key
technology. Private keys can be safely stored on a portable secure device and
signatures can be generated in a safe and trusted environment without endangering the disclosure of the signature key.
Public key technology, however, is supported by an infrastructure, that involves more than key storage and signature generation. Public Key Infrastructures (PKIs) require the deployment of certificate handling procedures, which
comprise certificate validation, path validation, and certificate status checking.
All these operations are essential for the proper use of digital certificates and
the legitimate use of a public key.
The limited computing resources and the lack of network connectivity, however, can negatively affect the card’s ability to handle those functions that support the deployment of public-key technology. As a result, smart cards are bound
to make limited and in many circumstances inappropriate use of public-key technology. The resources constraints that can affect the use of public-key technology
include the following.
?
This author’s work is also supported by the Information Management Department
of the same Institute.
– Low-power CPU, which restricts the amount of computations that can be
done within reasonable time. Reasonable in this context denotes how long
the user is willing to wait for the transaction to complete.
– Low throughput interface which restricts the amount of data that can be exchanged between the card and the hosting computer or the Card Acceptance
Device (CAD).
– Lack of an on-card clock renders the card incapable of processing any time
related information.
Although an off-card entity, such as the hosting computer, can efficiently
handle certificates on behalf of the smart card, we believe that this is a bad
practice. Certificate handling, an operation that is very closely related to signature verification and public-key encryption, should be considered as a security
sensitive operation. Given that, it should be done within a trusted environment.
Delegating certificate handling operations to an off-card entity, like the CAD or
the hosting computer, lurks many risks. Unless the CAD or the hosting computer are part of the Trusted Computing Base (TCB) these operations must not
be off-loaded.
This paper addresses issues that surround the deployment of PKI when employing smart cards as the security component used for storing and handling
certificates as well as performing critical cryptographic computations. In this
context, we assume that the card is not only used for signature generation and
key storage, but its functionality is extended to cover all those tasks that use of
public-key technology demands.
For the purposes of this paper we consider a typical electronic commerce application, adopted by multiple financial institutions, such as a transfer of money
or payments between two end entities. We assume that each entity that participates in the transaction bears a smart card used for certificate storage and validation, as well as signature generation and verification. We further assume that
there is no on-line clearing, a realistic assumption especially for small amounts,
and that an entity commits to the transaction by simply signing the amount
that is being transferred together with some other transaction related data. To
perform such a transaction one needs to do the following.
– Verify the peer’s signature on the amount.
– Validate the signatory’s certificate issued by a financial institution, which
might be different from the one that the verifier is associated with. This
certificate typically certifies the peer’s credentials and public key. It might
also grant authority to the signer to participate in this transaction.
– Validate the certificate of the accepting financial institution that establishes
a trust relationship between the two financial institutions. This will typically
be provided by a certificate chain.
2
Operational constraints of a smart card
In the following sections we investigate issues that surround the deployment of
public key technology with the use of smart cards as the security component
that stores cryptographic keys and performs security critical operations.
2.1
Certificate Validation
Certificate validation is obviously required when validating peer entity’s digital
signatures based on public key cryptography. It is one of the core tasks that have
to be performed during the transaction and the most demanding one in terms
of processing power, communication bandwidth and connectivity. Peer entity’s
certificate verification typically involves the following tasks.
– The process begins with a check on the credentials of the certificate owner
including the date that the certificate expires.
– If the certificate submitted to the verifier is the one that corresponds to the
signatory and it has not expired, the verifier proceeds with the construction
of a valid certificate path up to a trusted authority.
– Upon construction of the certificate chain, the verifier has to validate each
of the certificates that form the certificate chain. This process also demands
a check on the revocation status of each of these certificate.
– If the verification of the certificate path is successful, the verifier can proceed with the checks that his verification policy dictates which will typically
include revocation status checking.
A smart card faces major obstacles in performing each of these tasks in the
process of validating a certificate. The whole process is very expensive for a
smart card in terms of computing power, memory, and throughput. Validating
expiration is impossible without the use of an external trusted time server. Constructing a path also requires the use of a server due to card’s lack of network
connectivity.
2.2
Revocation status checking
Certificate revocation status checking is one of the main tasks to perform during
certificate validation. It is most important in situations where there is no trust
between the two participating entities. Rusell in [17] mentions that, “if a revoked
certificate is used by mistake, the fact will be discovered during routine checking
and no harm will be done. The certificate holder will probably be notified and
submit a current certificate. The security problem arises when a revoked certificate is used deliberately, implying that the attacker has a compromised key and
is impersonating the certificate owner”. Certificate revocation status checking
can tackle this problem as it can prevent the use of an invalid certificate by a
rogue user. Several schemes have been proposed [8, 12, 10, 9], including the standardised Certificate Revocation Lists (CRLs) [7, 8], and the widely used Online
Certificate Status Protocol (OCSP) [12].
Certificate revocation methods typically use timestamps to provide freshness,
i.e. ensure that the user will be provided with the latest information regarding
the status of a certificate. It is the responsibility of the certification authority,
or another authorised entity, to keep this information up to date, and make it
available to interested parties via pull or push methods. Access to a reliable time
clock is therefore vital when processing revocation status information.
Moreover, certificate revocation methods were designed to operate in environments where existence of sufficient computing and storage resources is not an
issue. Smart cards lack such resources and, therefore, they cannot adopt these
methods without significantly modifying them. The main problems that smart
cards face when dealing with certificate revocation issues are the following.
– Smart cards do not have the means to independently search and fetch the
revocation status information that they need as they do not enjoy networking
capabilities.
– Smart cards cannot check the freshness of the information provided to them
as the existing mechanisms mainly depend on time information.
Some of these issues can be resolved with the use of OCSP [12], which, when
slightly modified, allows the card to delegate revocation status checking to an
on-line authority. OCSP is a protocol that provides an alternative to the use
of time information for providing freshness, which is the use of nonces. More
importantly, the length of the messages exchanged with the card is considerably
short as they specifically target the certificate(s) in question as opposed to the
standardised Certificate Revocation Lists (CRLs) [8, 7], as well as other mechanisms, which provide information about a range of certificates. Still though,
certain modifications have to be applied to OCSP prior to being used by smart
cards. In the following sections we identify some of the issues that have to be
addressed when using OCSP with smart cards and propose viable solutions.
Card and CAD capabilities. In order to use OCSP in a smart card environment the following two requirements have to be satisfied.
– The card should be able to generate a random number that can be used as a
nonce for providing freshness to OCSP responses. If the card does not have
this capability, a serial number, unique to each query, can be used instead,
although this might make the card susceptible to replay attacks.
– As the card cannot initiate a communication with the responder, the computing platform that is connected to the CAD has to establish this communication session on behalf of the card. This computing platform must be
able to communicate with the appropriate authorised responder as well as
forward cards’ queries and receive servers’ responses, which will transmit to
the card.
In a typical use of OCSP by a smart card the following steps have to be
followed. The communication outline is depicted in Figure 1.
1. When the card receives a certificate and wants to query its revocation status,
it should generate a “nonce” and forward it to the CAD to indicate that the
card requires revocation status information about this certificate. As the card
cannot initiate a communication session with the CAD and hence, with the
corresponding server, it should either use the last communication with the
CAD to send the “nonce”, i.e. as a response or warning to the last command,
or wait for the CAD to send the appropriate command before generating the
random number and sending it back to the CAD . The card should also send,
as part of this message, identification data for the certificate in question
and information about the authority whose responses the card is willing to
accept and consider as valid. The CAD, on receipt of this information, should
construct an appropriate OCSP request, based on the information provided
by the card and forward it to the appropriate authority. The random number
that the card gives to the CAD will be the value of the optional “nonce”
extension [12] and form part of the request.
2. Upon receipt of the card’s request, which is effectively sent by the CAD, the
responder has to check the status of the certificate in question as required by
the OCSP protocol. However, given the existence of the “nonce” extension in
the request, which is essential for providing freshness, the OCSP responder
must include the “nonce” extension in the signed response and send it back
to the CAD, which in turn has to forward the response to the card.
3. The card has to verify the signature on the response data and most importantly, check that there is a “nonce” included in the response and is identical
to the one that the card sent with the request.
Fig. 1. OCSP communication
Nonce extensions should be critical A nonce in OCSP “binds a request and
a response to prevent replay attacks” [12], and therefore, can provide freshness
to the generated responses. OCSP’s “nonce” extension, however, is optional and
as such it might not be part of a request. In the smart card context, the “nonce”
extension must always be present and, in the OCSP terminology, the extension
should be marked as critical, as opposed to OCSP’s recommendation that “the
critical flag SHOULD NOT be set for any of them [request extensions]”. This
is to ensure that the responder will not ignore the extension, but process it and
include it in the response for the smart card to check its presence and validity.
Responder’s certificate validation If the card does not have an established
relationship with the OCSP responder, validation of an OCSP response would
also require validation of the responder’s certificate. Apart from verifying that
the responder’s certified key is authorised to sign OCSP responses, the card has
to validate the revocation status of this certificate. The two methods suggested
in [12], i.e. the use of CRLs or the use of certificates with short lifetime, are not
suitable for smart cards.
To validate the revocation status of an authorised responder certificate the
card has to maintain a list of revoked certificates for its lifetime instead. This
list is similar to a CRL except for the following.
– It is the responsibility of the off-card management system to update this list
with any revoked responders’ certificates. It is anticipated that this list will
be small enough for a card to maintain and process as it will only contain
responders’ certificates. It can be updated by using push methods.
– Expired certificates will not be removed from the list as it is the case with
CRLs. On the contrary, OCSP responders’ expired certificates should be
added to this list for the card to check during response verification. This will
provide the card an efficient way to check the certificate’s expiration date.
– No regular updates are anticipated and therefore, information that typical
CRLs contain, like the nextUpdate field and the CRL number extension, is
not required.
As an alternative, the card issuer might only load to the card the public keys
of the acceptable authorised OCSP responders. In that case, the card has to get
an OCSP response from one of the responders whose public key is pre-loaded on
the card. It will then be the responsibility of the off-card management system to
either delete the revoked key from the list of keys or replace it with the updated
key.
Response generation and replay attacks A problem that arises from the
use of nonces for freshness purposes is that the server cannot pre-produce OCSP
responses as it is suggested in [12]. The server has to wait for the user’s challenge to generate the corresponding information, which can lead to performance
downgrade in situations where the server experiences a high volume of requests.
The benefit of generating real-time responses combined with the use of nonces,
is that the protocol is not susceptible to the replay attacks mentioned in [12]
where “an old (good) response is replayed prior to its expiration date but after
the certificate has been revoked”.
Lack of time information in the response however, might allow an attacker to
mount another kind of replay attack. More specifically, an attacker can issue a
large number of requests regarding either a specific or various certificates using
different random numbers. Gathering the corresponding responses and maintaining them for a period of time that exceeds their normal expiration date,
i.e. the date that would be included in a typical OCSP response, would allow
an attacker to use them after the revocation of a certificate and the response
expiration date. The attacker can replace the OCSP sever’s response with an
invalid one that states that the certificate in question is still valid.
Although such an attack is hard to mount, as it requires the attacker to
be able to “guess” the random number, we believe that it is not unlikely to
happen. This risk can be further reduced by including the card’s id in the OCSP
response. In that case the attack should target a specific card demanding the
attacker to have knowledge of the card’s id, and to guess the random number
and the certificate for which the card will issue a request. Inclusion of card’s id
in the response is critical if serial numbers are used instead of random numbers,
as they are considered more predictable and, therefore, make the attack far more
easier to mount.
Note that, although OCSP resolves one of the most important issues in certificate validation, i.e. certificate revocation status checking, it does not provide
an integral solution to the handling of digital certificates problem. Further issues
are addressed in the following sections.
2.3
Can we trust the CAD to do the certificate validation and the
signature verification?
A smart card, as previously mentioned, is typically used for storing sensitive
information, such as cryptographic keys, and performing security critical computations, such as signature generation. It’s intended purpose is not to perform
certificate validation and signature verification. These two processes do not require use of sensitive data and, in that sense, they can be delegated to the hosting
computer, which typically has, or can easily obtain, all the required information.
There are major security concerns, however, if these two operations do not take
place on the card.
– If the hosting computer does the certificate validation on behalf of the card
there is a need to ensure that it adheres to the corresponding application’s
verification policy.
– A rogue hosting computer, or a virus infected one, might present the card
with a wrong verification or validation result, in an attempt to deceive the
card so that a non-valid certificate will be considered as valid.
Therefore, the legitimacy of the certificate verification result can be questioned. These concerns are mounting if the hosting computer is not part of the
TCB. Certificate path validation cannot be assigned to a device that is not part
of the TCB. The card might operate in a hostile environment and therefore the
robustness of the on-card application should not depend on other non-trusted
communicating devices.
2.4
Certificate Storage
A PKI application typically requires storing CAs certificates at the user’s system,
for validating a certification path, as well as end entities’, i.e. both cardholder’s
and peer entities’, certificates.
Root Certificate Storage. Storing CAs’ certificates locally, is typically required by applications that utilise public key technology for validating certificates issued by this authority. Although it is anticipated that in most cases only
a single CA public key has to be stored in the card, which does not actually
constitute a major obstacle, the number of CAs’ public keys stored in the card
can be significantly altered due to infrastructure demands that might dictate
storage of keys from multiple CAs. For instance, in our electronic commerce application the card might store certificates from other financial institutions, thus
simplifying the card’s process when participating in transactions with customers
from those institutions.
The problem sharpens in multi-application smart cards where card space is
shared among multiple application providers [15] who have to load their own
root certificate(s) for the applications they own and are loaded on the card.
Note that, because the card cannot validate expiration dates, the card issuer
might only preload the CAs public keys instead of the corresponding certificates.
In any case it would be the responsibility of the off-card management system to
update, replace, or delete these public keys or certificates.
Cardholder’s certificate(s) storage. In a typical PKI application the user
has his own certificates stored in his system for providing them to the peer during
the transaction. The situation with smart cards is rather different. Although it
is anticipated that the size of the cardholder’s certificate(s) will be significantly
shortened and adapted to the smart card restrictions, it is questionable whether
cardholder’s certificate(s) should be stored in the card to pass to peer entities.
Such an approach bears the risk of having the card passing an expired certificate
to the peer and, therefore, exposing the cardholder to the threat of falsely being
accused of participating in an invalid transaction.
As with root certificates, cardholder’s certificate management, such as certificate renewal and removal due to expiration or revocation, has to be done by
the off-card management system. Although it is anticipated that the off-card
management system will attempt to update the certificate with a new one well
before its expiry date, this cannot preclude the situation where the cardholder
will only use his card for off-line transactions, hence bearing the aforementioned
risk of using an expired certificate.
Peer Entities’ certificates storage. It is common practice for PKI applications to allow end-users to store valid peer entities’ certificates used in a transaction so that they can be reused with little overhead (reusing them requires
only checking their status and the expiry date).
On-card applications would save a lot on bandwidth and processing power if
they stored peer entities certificates for subsequent transactions. Even if card’s
storage space does not prohibit this action, cards should refrain from doing so,
as the card does not have the capability to check whether a certificate stored in
it has expired or not.
As a result, the card has to discard all peer entities’ certificates upon the
transaction’s completion, even if the card has frequent communications with the
same peer. This action has direct implications on the application’s performance.
Discarding peer entities’ certificates leads to further processing and communication delays, which, in environments like that of a smart card, are even more
noticeable.
2.5
Path Discovery and Validation
In situations where a complete certificate chain up to a trusted CA is not provided by the peer, the PKI application has to construct a valid certification path.
Smart cards are devices that lack networking capabilities and, in this context,
they entirely depend on the CAD or hosting computer. The card cannot act
independently in gathering all the required information. As a result, if the card
requires communication with an on-line authority to retrieve certificate(s) or certificate validation information, it has to either do this via the hosting computer
or delegate this task to the hosting computer, assuming that the latter has such
capabilities.
Although path discovery is not a security critical operation and, therefore,
it can be delegated to the hosting computer, certificate validation has different
requirements. It can only be performed by a device that is part of the TCB, and
more specifically, by a device that is authorised to collect and validate this information on the card’s behalf. Delegating this task to the hosting computer bears
many risks with the most important one being that a rogue hosting computer
might try to deceive the card by either presenting a wrong path validation result
or omitting doing the validation.
Although path discovery and validation cannot be delegated to the hosting
computer, it can be performed by a remote trusted and authorised server. The
Simple Certificate Validation Protocol (SCVP) [5] provides this functionality
and, therefore, it can be used for this purpose. Although SCVP is still in the
Internet Engineering Task Force (IETF) draft process, it can prove very useful
for smart cards as it allows an authorised server to collect all the necessary
certificate validation information and, given that the server is trusted, validate
this information on behalf of the card.
If SCVP is adopted by smart cards it has to be exclusively used with trusted
servers as, apart from certificate path construction, smart cards also have to delegate certificate path validation. In that case the trusted server has to construct
the path up to the card’s CA and validate each of the certificates in the path,
including the end entities’ certificate.
With the use of SCVP the card can validate the certificate chain with one
signature verification or with the validation of a MAC. Clearly though, and due
to the fact that smart cards cannot handle time information, the server should
not be using timestamps for providing freshness, hence, nonces should be used
instead.
Note that, use of SCVP implies card’s dependance on CAD’s networking capabilities for performing path discovery and validation, a situation that exposes
the card to the following threat. A rogue CAD might deliberately deny the connection to the on-line authority in an attempt to force the card to commit to the
transaction without making the appropriate validation checks (assuming that
this is allowed by the application’s policy).
2.6
Evidence storage
In cases where there are disputes between the two entities, evidence regarding
the specific transaction has to be used to solve them. In that case, a server’s
response regarding the peer entity’s certificate status might prove useful.
The data that the card typically has to retain for this purpose includes the
following.
– The peer entity’s digital signature on the transaction. Note that, the data
signed by the peer should contain information about the certificate that is
used for verifying the signature.
– The server’s response on the status of the certificates, both the peer’s certificate and the certificates in the path, or, in the case that SCVP is used, the
validation result. Generally, if certain functions are delegated to an off-card
entity, the evidence produced by that entity might have to be retained as
legal evidence for solving disputes.
Cards are devices with limited storage capabilities, and as such they are incapable of retaining significant amount of data for these purposes. If the amount
of evidence data stored in the card reaches the space limits allocated for this
purpose, the card faces the threat of either not being able to commit to further
transactions, or delete, potentially valuable, evidence from previous transactions.
3
Conclusions
Smart cards can form a critical component in the deployment of PKIs due to
their tamper resistance and mobility which offer a very attractive environment
for storing private keys and performing cryptographic computations. One of the
major problems however, that smart cards face is their inability to cope with
many of the supporting mechanisms of a PKI, such as certificate revocations. Use
of protocols like a slightly modified, as proposed in this paper, OCSP can prove
very useful as opposed to more conventional certificate revocation methods, like
the standardised CRLs. Furthermore, use of SCVP can boost the deployment
of PKI enabled on-card applications as it provides, an otherwise prohibitive for
smart cards, method for constructing and validating certificate paths. We believe
that protocols being designed for supporting the use of public-key technology
should also consider smart card needs, as these are identified in this paper, to
further boost the deployment of public-key technology.
References
1. A. Arnes, M. Just, S.J. Knapskog, S. Lloyd, and H. Meijer. Selecting revocation
solutions for PKI. In Proceedings of the 5th Nordic Workshop on Secure IT Systems,
Reykjavik, Iceland, October 2000.
2. D.A. Cooper. A model of certificate revocation. In Proceedings of the Fifteenth
Annual Computer Security Applications Conference, pages 256–264, December,
1999.
3. D.A. Cooper. A more efficient use of delta-CRLs. In Proceedings of the 2000 IEEE
Symposium on Security and Privacy, pages 190–202, May, 2000.
4. W. Ford and M.S. Baum. Secure Electronic Commerce. Prentice Hall PTR, 1997.
5. T. Freeman, R. Housley, A. Malpani, D. Cooper, and T. Polk. Simple Certificate
Validation Protocol (SCVP). Internet Draft, February 2005.
6. C. Gehrmann, K. Nyberg, and C.J. Mitchell. The personal CA - PKI for a Personal
Area Network. In Proceedins – IST Mobile & Wireless Communications Summit
2002, pages 31–35, Thessaloniki, Greece, June 2002.
7. R. Housley, W. Polk, W. Ford, and D. Solo. Internet Public Key Infrastructure,
Certificate and Certificate Revocation List (CRL) Profile. RFC 3280.
8. ITU. Information technology—Open Systems Interconnection—The Directory:
Public–key and attribute certificate frameworks, March 2000.
9. P. Kocher. On certificate revocation and validation. In R. Hirschfeld, editor,
Financial Cryptography, Anguilla, 1998, pages 172–177. Springer-Verlag (LNCS
1465), Berlin (1998).
10. S. Micali. Efficient certificate revocation. Technical Report MIT-LCS-TM-542b,
Massachusetts Institute of Technology, March 1996.
11. J.F. Muñoz, J.L. Muñoz, and J.C. Castro. Certificate revocation for e–business,
e–commerce and m–commerce. In International Conference on Advances in Infrastructure for Electronic Business, Science, and Education on the Internet (SSGRR
2001), August, 2001.
12. M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. X.509 Internet
Public Key Infrastructure, Online Certificate Status Protocol – OCSP. RFC 2560.
13. M. Naor and K. Nissim. Certificate revocation and certificate update. In Proceedings 7th USENIX Security Symposium, San Antonio, Texas, 1998.
14. D. Pinkas and R. Housley. Delegated Path Validation and Delegated Path Discovery Protocol Requirements. RFC 3379.
15. Global Platform. Card specification, version 2.1.1. March 2003.
16. R.L. Rivest. Can we eliminate certificate revocation lists? In R. Hirschfeld, editor,
Financial Cryptography, Anguilla, 1998, pages 178–183. Springer-Verlag (LNCS
1465), Berlin (1998).
17. S. Russell. Fast checking of individual certificate revocation on small systems. In
Proceedings of the Fifteenth Annual Computer Security Applications Conference,
pages 249–255, December, 1999.