Deployment Tool with TLS
83
Deployment Tool with TLS
The following is an attempt to explain briefly how TLS (
T
ransport
L
ayer
S
e-
curity) works and how IP phones use it. In particular, it explains the central
role of certificates.
Public Key (Asymmetric) Cryptography
Two parties A and B wish to communicate with each other. Each has its
own pair of public and private keys. Each public key only matches its cor-
responding private key, and vice versa. Each party keeps their private keys
secret, while distributing their public keys to the world at large.
A wishes to send B encrypted information. A encrypts the message with
B's public key. B decrypts the message with B's private key. Only B can
decrypt the message, since only B has the private key which matches the
public key with which the message was encrypted.
A wishes to sign a message sent to B. A signs the message by encrypting
a digest of the message with A's private key. B decrypts and checks the
signature using A's public key. Since only A has the private key which
matches A's public key, the message must have been sent by A.
Certificates
A message can only be verified as being signed by A if the public key used
to check the signature is known to belong to A. To this end, public keys are
distributed as certificates, which are signed by an issuing Certificate Au-
thority (CA). Each certificate contains :-
•
the subject's distinguished name (DN), e.g. A,
•
the subject's public key,
•
the issuer's DN, e.g. C,
•
the certificate's serial number (unique within all certificates issued by
C),
•
the calendar period during which the certificate is valid,
•
the signature (a digest of the certificate, encrypted using the issuer's
private key).
The public key held by a certificate is known to belong to the certificate's
subject if the certificate's signature can be checked using the issuer's pub-
lic key. The issuer's public key is obtained from the issuer's own certifi-
cate, which in turn has been issued by another CA, e.g. D. A certificate
chain forms (A -> C -> D -> etc), until a CA is reached (e.g. E) who is
deemed trustworthy by the user, e.g. B. B has a copy of E's certificate
(possibly obtained from E directly), and uses this to validate the certificate
chain ACD.
A's certificate is not that of a CA, and is termed an end-entity certificate.
A CA certificate may not have a separate issuer – it may be signed with the
private key corresponding to the certificate's public key – and is termed a
self-signed certificate.
