Siemens V1.2.33 manual Tls, Certificate File Formats

Deployment Tool with TLS

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.

84