RFID Guardian Security Protocols Asym

From RFID Guardian

Asymmetric key protocol (also known as Public Key Cryptography) is an arrangement that makes use of a pair of keys - public key and private key. Users keep the private key secret and publish the public key, i.e. by declaring it on a website. So when Alice wants to send a message to Bob, then Alice should first find Bob's public key, then Alice should encrypt that message with that key. When Bob receives this encrypted message, he can decrypt it with his private key. Even if that message may be overheard by somebody else (say Carol), that person cannot read the message, because Carol does not have Bob's private key. In other words, the two parties that are communicating do not need to share secrets. Because of this important feature asymmetric key protocol has been widely deployed in many applications: authentication of web services, secure email, electronic signatures, etc.

A central problem with asymmetric key protocol is proving a public key is authentic, and has not been tampered with or replaced by a malicious third party. Suppose that Carol declares her public key to be Bob's, and Alice believes this declaration for whatever reason. Then when Alice encrypts her message and sends that to Bob, Bob cannot decrypt that message, because Bob does not have the right private key. But if Carol can get this message, she can decrypt it! In practice, the usual solution is to use a Public Key Infrastructure (PKI), in which we use certificates to verify the relationship between the public key and the entity who claims ownership of it.

A certificate is a piece of message that reliably associates a particular identity to a particular public key. This reliability is guaranteed by the fact that the certificate is signed and issued by a Trusted Third Party (usually known as Certification Authority (CA)) that all the parties of the system assume trust with respect to issuing authentic certificates.

Certificate Authority

Certificate Authority (CA) is the organization that generates certificates in the PKI and has the responsibility to certify ownership of key pairs. Two basic organization models of CA are:

Centralized CA: Most centralized CAs are commercial and make profit by signing the customer's public keys. Usually when an individual person or an organization needs a certificate from the CA, public key must be sent to the CA, together with documents proving the authenticity of the key and of the entity requesting the certificate. This conventional evidence bootstraps trust in the digital scenario. For an individual, documentation could be an Identification Card; for an organization, it could be its registration with the chamber of Commerce. When the CA is convinced that the public key really belongs to the identity, then it will sign the identities certificate. Some centralized CAs have such a good and global reputation that certificates signed by them can be recognized almost anywhere. The market leading CA is VeriSign.

One benefit of a centralized CA is that if the CA has a good reputation it can be trusted by everyone. There are however two disadvantages: 1) it means extra charges for the user, and 2) the user may have to wait a few weeks.

One important feature of certificates is that they can be chained, i.e. each certificate can refer to sequence of previous certificates. The purpose of a certificate chain is to establish a chain of trust from a `peer' certificate to a trusted CA certificate. The CA vouches for the identity in the peer certificate by signing it. If the CA is one that you trust (indicated by the presence of a copy of the CA certificate in your root certificate directory), this implies you can trust the signed peer certificate as well.

Localized CA: if the public key is not used in a generic \emph{public place}, but instead only within a single organization (i.e. a small company) then there is no need to use to a centralized CA. For example, some buildings use an RFID card as proof of entry. In this case there is no need to have VeriSign sign the certificates; the administration office can instead set up a local CA and sign these cards directly.

Two advantages with local CA are: 1) there is usually no extra fee. 2) these certificates can be generated immediately. However, the disadvantage is this local CA cannot be trusted by the public.

Different models have different advantages and disadvantages. A more detailed discussion and comparison of CA usage for RFID systems is given elsewhere

Certificate Revocation

Public key certificates today are usually based on X.509, and in addition to the public key, they tend to carry more information to make them easier to use, including:

Date of Issue

Expiration date

Version of this certificate format

Indications of types of keys formats

Owner's name in various formats

Other properties of the owner (for example, address)

Owner's rights and privileges

Most of this information is clear: it has either to do with the public key (key format, etc), with the owner (owner's name, address, etc), or with the certificate itself (issue date, certificate format, etc). The purpose of the expiration date is less straightforward. A certificate cannot stay valid forever, because:

CA might improperly issued a certificate.

The private key could become compromised.

The user could lose sole possession of the private key (e.g. the key could get stolen or lost).

So certificates need to be revoked from time to time. Techniques for revocation can be roughly divided into two strategies: on-line and off-line. With on-line revocation, the end user will call a Certificate Authority (CA) on-line (Internet, for example) to check the certificates's real status; With off-line revocation, CAs will periodically publish a good list or bad list of the certificates signed by that CA.

Although on-line revocation provides the best security for end users, in practice off-line revocation is for more common, since it does not require a network facility. This is a trade-off between security and convenience. These two techniques are discussed in this site with reference to RFID Guardians.