Deployment Tool with TLS, Certificates

Deployment Tool with TLS

The following is an attempt to explain briefly how TLS (Transport Layer Se- 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.