RFID Guardian Security Protocols Asym
From RFID Wiki
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.
[edit] 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
[edit] 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.


