Secure socket layer (SSL) for STM32F417xx microcontrollers
1 Introduction
STM32F417xx microcontrollers feature a complete 10/100 Mbit/s Ethernet peripheral that
supports both the Media Independent Interface (MII) and Reduced Media Independent
Interface (RMII) to interface with the Physical Layer (PHY), with hardware checksums of the
IP, UDP, TCP and ICMP protocols.
One of the advanced features of the STM32F417xx is the hardware cryptographic processor
for AES/128/192/256, Triple DES, DES, SHA-1, MD5 and RNG.
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) cryptographic protocols
provide security for communications over networks, such as the Internet, and allow client
and server applications to communicate in a way that is private and secure.
The purpose of this application note is to present a demonstration package built on top of a
free SSL/TLS library: the PolarSSL library.
AN3967
Application note
This application note is structured as follows:
●A short glossary is provided in Section 2.
●A general introduction to SSL/TLS is presented in Section 3.
●Section 4 introduces the PolarSSL library.
●Section 5 describes the STM32F417xx hardware cryptographic processors.
●Lastly, Section 6 describes the demonstration package for STM32F417xx.
Note:This application targets only STM32F417xx devices, since the cryptographic acceleration is
not embedded in STM32F407xx devices, and it uses the STM3241G-EVAL board as a
hardware platform.
The Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocols provide
communications security over the Internet and allow client/server applications to
communicate in a way that is private and reliable. These protocols are layered above a
transport protocol such as TCP/IP.
SSL is the standard security technology for creating an encrypted link between server and
client. This link ensures that all communication data remains private and secure.
The major objectives of SSL/TLS are:
●Provide data integrity between two communicating applications.
●Protect information transmitted between server and client.
●Authenticate the server to the client.
●Allow the client and server to select the cryptographic algorithms that they both
support.
●Optionally authenticate the client to the server.
●Use public-key encryption techniques to generate shared secrets.
●Establish an encrypted SSL connection.
3.1 SSL application layers
The SSL/TLS application consists of five layers:
●Application layer: the Application Layer refers to the higher-level protocols used by
most applications for network communication.
●SSL/TLS layer: the SSL/TLS layer provides security communication over the Internet.
●TCP layer: the Transport Layer's responsibilities include end-to-end message transfer
capabilities independent of the underlying network, along with error control,
segmentation, flow control, congestion control, and application addressing.
●IP layer: the Internet Protocol layer is responsible for addressing hosts and routing
packets from a source host to the destination host.
●Physical layer: the Physical Layer consists of the basic hardware transmission
technologies of a network.
Doc ID 022106 Rev 17/41
SSL / TLS protocol overviewAN3967
Application layer
SSL/TSL layer
TCP layer
IP layer
Physical layer
MS18970V1
Figure 1.SSL application architecture
3.2 History of the SSL / TLS protocols
SSL was developed by Netscape in 1994 to secure transactions over the Internet. Soon
after, the Internet Engineering Task Force (IETF) began work to develop a standard protocol
to provide the same functionality.
●SSL 2.0 (Netscape, 1994): This version contained a number of security flaws.
●SSL 3.0 (Netscape, 1996): All Internet browsers support this version of the protocol.
●TLS 1.0 (IETF, 1999): This version was defined in RFC 2246 as an upgrade to SSL 3.0.
“The differences between this protocol and SSL 3.0 are not dramatic, but they are
significant enough that TLS 1.0 and SSL 3.0 do not interoperate”: [1]: RFC 2246: The
TLS protocol version 1.0
Note:The “SSL/TLS” protocols is referred to as “SSL” throughout this document.
3.3 SSL / TLS sub-protocols
The SSL protocol includes four sub-protocols: the SSL Record protocol, the SSL
Handshake protocol, the SSL Alert protocol and the SSL Change Cipher Spec protocol.
Figure 2.SSL sub-protocols
8/41Doc ID 022106 Rev 1
AN3967SSL / TLS protocol overview
3.3.1 SSL Handshake protocol
The SSL session state is controlled by the SSL Handshake protocol. This protocol involves
using the SSL record protocol to exchange a series of messages between SSL server and
SSL client when they first start communicating. This exchange of messages is designed to
facilitate the following actions:
●The protocol version SSL 3.0 or TLS 1.0
●Allow the client and server to select the cryptographic algorithms, or ciphers, that they
both support
●Authenticate the server to the client
●Optionally authenticate the client to the server
●Use public-key encryption techniques to generate shared secrets
●Establish an encrypted SSL connection
Figure 3.SSL Handshake protocol
Doc ID 022106 Rev 19/41
SSL / TLS protocol overviewAN3967
The following is the procedure for SSL Handshake protocol:
1.The client sends a ClientHello message specifying the highest SSL protocol version
(SSL 3.0 or TLS 1.0) it supports, a random number, a list of cipher suites and
compression methods.
2. Server responds with a ServerHello message that contains the chosen protocol
version, another random number, cipher suite and compression method from the
choices offered by the client, and the session ID.
Note:The client and the server must support at least one common cipher suite, or else the
Handshake protocol fails. The server generally chooses the strongest common cipher suite
they both support.
3. The server sends its digital certificate in an optional certificate message, for example,
the server uses X.509 digital certificates.
4. If no certificate is sent, an optional ServerKeyExchange message is sent containing the
server public information.
5. If the server requires a digital certificate for client authentication, an optional
CertificateRequest message is appended.
6. The server sends a ServerHelloDone message indicating the end of this phase of
negotiation.
7. If the server has sent a CertificateRequest message, the client must send its X.509
client certificate in a Certificate message.
8. The client sends a ClientKeyExchange message. This message contains the premaster secret number used in the generation of the symmetric encryption keys and the
message authentication code (MAC) keys. The client encrypts pre-master secret
number with the public key of the server.
Note:The public key is sent by the server in the digital certificate or in ServerKeyExchange
message.
9. If the client sent a digital certificate to the server, the client sends a CertificateVerify
message signed with the client's private key. By verifying the signature of this message,
the server can explicitly verify the ownership of the client digital certificate.
10. The client sends a ChangeCipherSpec message announcing that the new parameters
(cipher method, keys) have been loaded.
11. The client sends a Finished message; it is the first message encrypted with the new
cipher method and keys.
12. The server responds with a ChangeCipherSpec and a Finished message from its end.
13. The SSL Handshake protocol ends and the encrypted exchange of application data
can be started.
10/41Doc ID 022106 Rev 1
AN3967SSL / TLS protocol overview
Resuming SSL session
When the client and the server decide to resume a previous session or to duplicate an
existing session (instead of negotiating new security parameters), the message flow is as
follows:
1.The client sends a ClientHello message using the Session ID of the session to be
resumed.
2. The server checks its session cache for a match. If a match is found, and the server is
willing to re-establish the connection under the specified session state, it sends a
ServerHello message with the same Session ID value.
3. Both client and server must send ChangeCipherSpec messages and proceed directly
to the Finished messages.
4. Once the re-establishment is complete, the client and server may begin to exchange
encrypted application data.
Note:If a Session ID match is not found, the server generates a new session ID and the client and
server perform a full Handshake protocol [1]: RFC 2246: The TLS protocol version 1.0.
Figure 4.Handshake protocol to resume an SSL session
Doc ID 022106 Rev 111/41
SSL / TLS protocol overviewAN3967
Application data
-F1--F2--Fn-
Compression
Fragment
Authentification
Encryption
MS18971V1
3.3.2 SSL Record protocol
The Record protocol takes messages to be transmitted, fragments the data into
manageable blocks, optionally compresses the data, applies a MAC, encrypts, and
transmits the results.
The received data is decrypted, verified, decompressed, and reassembled, then delivered to
higher level clients.
Figure 5.SSL Record protocol
3.3.3 SSL Alert protocol
The SSL Alert protocol signals problems with the SSL session ranging from simple warnings
(unknown certificate, revoked certificate, expired certificate) to fatal error messages that
immediately terminate the SSL connection.
3.3.4 Change Cipher Spec protocol
The SSL Change Cipher Spec protocol consists of a single message that indicates the end
of the SSL Handshake protocol.
Note:For more information about SSL protocols, please refer to [1]: RFC 2246: The TLS protocol
version 1.0.
12/41Doc ID 022106 Rev 1
AN3967PolarSSL library
4 PolarSSL library
PolarSSL is a light-weight open source cryptographic and SSL/TLS library written in C. This
library contains all needed functions to implement an SSL/TLS server or client. It contains
also a set of hashing functions and cryptographic algorithms.
●Public key cryptography: RSA and Diffie-Hellman (DHM) key exchange
The source code of the PolarSSL library can be downloaded from this link:
http://polarssl.org/download_overview
4.1 License
PolarSSL is licensed according to the dual licensing model. PolarSSL is available under the
open source GPL version 2 license, as well as under a commercial license for closed source
projects.
For detailed information about licensing, please refer to the PolarSSL licensing webpage
http://polarssl.org/licensing
Doc ID 022106 Rev 113/41
Loading...
+ 28 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.