Siemens HIPATH V1.2.33 - Manual (Page 84)

Deployment Tool with TLS
84
TLS
TLS (Transport Layer Security) allows the encryption of existing protocols
over TCP, and allows the two parties of a connection to validate each oth-
er's identity. For efficiency, symmetric ciphers are used to encrypt the data
sent, each party using the same key to encrypt and decrypt data. The TLS
handshake, performed at the start of each TLS connection, uses public key
cryptography to create the symmetric cipher key shared by both parties,
and to allow both parties to validate each other's identity.
The TLS client opens a TCP connection to the TLS server, and initiates the
handshake by sending a Client Hello message. The server replies with a
Server Hello message, containing the server's public key certificate in a
certificate chain. The client authenticates the chain using its own copy of
a certificate of a trusted CA, and sends a Client Key Exchange message,
containing the symmetric cipher key encrypted with the server's public
key. The server decrypts the cipher key, using its own private key, and re-
plies with a Finished message, encrypted with the symmetric cipher. The
client completes the handshake by returning a cipher-encrypted Finished
message.
Hence, a TLS server requires key material (a public key certificate (at the
end of a chain of CA certificates), and a matching private key), while a TLS
client requires a trusted CA certificate, with which to validate the server's
certificate chain. If the client does not wish to authenticate the server's
identity, it does not require the trusted certificate.
The handshake described above details server authentication by the client.
The handshake can be extended to allow the server to authenticate the cli-
ent, in addition. For this, the client needs its own key material, while the
server needs a trusted certificate with which to authenticate the client's
certificate chain. The phone's TLS server does not perform client authen-
tication.
Certificate File Formats
Certificates and private keys are encoded in ASN1 to PKCS standards. Us-
ing Microsoft Internet Explorer for reference, public key certificates (certif-
icate chains and trusted certificates) are imported and exported as binary
(.cer) files, base64 (.cer) files and PKCS#7 (.p7b) files. The binary format
contains a single ASN1-encoded certificate. The base64 format contains
the same binary data, translated into base64-encoding (i.e. translated into
ASCII), with "begin certificate" / "end certificate" guards, i.e. PEM format.
The base64 format can contain multiple certificates, by concatenating sep-
arate base64 files together. The binary PKCS#7 files contain multiple
ASN1-encoded certificates, with additional ASN1 encoding.
Key material is imported and exported as binary PKCS#12 (.pfx or .p12)
files, containing multiple ASN1-encoded certificates, and ASN1-encoded
private keys. PKCS#12 supports password encryption of its contents,
which is necessary for securing the private keys.