Siemens V1.2.33 用户手册

下载
页码 92
Deployment Tool with TLS
83
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.