STSAFE-A110 datasheet(13/36 Pages) STMICROELECTRONICS

13 / 36 page

DS13039 Rev 1

13/36

STSAFE-A110

Asymmetric cryptography use cases

•

Signature verification with ECDSA and a public key that is sent by the local host to the

STSAFE-A110. It is useful for verifying the peer's certificate chain in the Certificate

message. It is also useful for verifying the signatures in the Server Key Exchange

message and Certificate Verify message. The local host is responsible for generating

the SHA-256 or SHA-384 message digest and for sending the digest to the STSAFE-

A110 together with the public key and a reference to the curve that must be used.

•

Ephemeral key pair generation in the STSAFE-A110. It is useful when ECDHE has

been chosen as the key exchange algorithm. the STSAFE-A110 stores the private key

and returns the public key to the local host for inclusion in the Server Key Exchange

and Client Key Exchange messages.

•

ECDH or ECDHE with a static (ECDH) or an ephemeral (ECDHE) private key in the

STSAFE-A110. The local host must send the peer's public key from the Server Key

Exchange or Client Key Exchange message to the STSAFE-A110, which returns the

shared secret that is encrypted with the Host’s Cipher Key. After decryption with the

Host’s Cipher Key, the local host can use the shared secret as the pre-master secret of

the TLS handshake protocol.

The STSAFE-A110 does not implement the following cryptographic mechanisms of the TLS

handshake protocol:

•

conversion of the pre-master secret into the master secret

•

generation of the verify data in the Finished message

•

expansion of the master secret into a key block that may include a client write MAC

key, a server write MAC key, a client write encryption key, a server write encryption key

and two initial values

•

MACing, encryption and decryption of application data with keys from the key block

The command flow illustrates the integration of the STSAFE-A110 on the TLS client’s side

using ECDSA as the signature algorithm and ECDHE as the key exchange algorithm. The

STSAFE-A110 can also be integrated on the TLS server’s side but this is not illustrated

here.

Command flow (see Figure 7)

The TLS client sends the Client Hello message including the client version, a random

that can be obtained from the STSAFE-A110 with the Generate Random command (1),

a session ID, the list of supported cipher suites and compression methods and an

extension that lists the supported signatures and hash algorithms.

The TLS server sends the Server Hello message including the protocol version, a

random, a session ID and the chosen cipher suite and compression method. The TLS

server also sends the Certificate message including the X509 certificate chain of the

TLS server. Upon reception of this message, the local host of the TLS client may use

the STSAFE-A110 for verifying the certificate chain. Therefore, the local host must

parse every certificate from the chain, hash the To Be Signed (TBS) data and send the

Verify Signature command (2) to the STSAFE-A110. In the Verify Signature command

data, the local host must include a reference to the curve that must be used, the public

key, the signature and the hash. The STSAFE-A110 responds with an indication of

whether the verification was successful or not. When the certificate chain is composed

of more than one certificate, the Verify Signature command must be sent as many

times as there are certificates in the chain (this is not illustrated in Figure 7).

STSAFE-A110 Folha de dados(PDF) 13 Page - STMicroelectronics

STSAFE-A110 Folha de dados(HTML) 13 Page - STMicroelectronics

Html Pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

Folha de dados Download

Ligação URL