Hi, I'm Nick Lethaby,
the IoT Ecosystem
Manager at Texas Instruments.
I'm giving a five-part
training series
entitled "Understanding
secure connectivity
in IoT and embedded
assistive devices."
This is the fifth module
in the series entitled,
"How do common IoT software
applications use cryptography?"
And we're going to walk through
a number of software functions,
such as establishing a secure
network connection using TLS,
performing a secure
remote update,
performing secure provisioning
of security credentials
to an IoT device,
and then finally,
look at how many certificates
are needed on an IoT device.
You may find that it
helps to take the earlier
modules to fully understand
some of the terminology
and technology discussed
in this particular module.
To give you a better perspective
of all the cryptography
and security concepts
you've learned
in the previous
modules, we're going
to walk through
some examples of how
cryptography and
certificates are
used in real-world software.
The first example, we'll walk
through how a TLS connection is
established, then we will look
at how an IoT endpoint can
be provisioned with a
certificate using a certificate
signing request.
Next, we'll look at
over-the-air updates, which
is how you can securely perform
a remote update to a IoT
endpoint.
Then finally, we'll look at
all the certificates required
in an IoT endpoint
to make sure you
have a good grasp of different
ones needed in the endpoint.
Before we get into the
details of exactly how the TLS
protocol uses the various
cryptographic concepts we've
discussed in
earlier modules, I'd
like to talk a bit
more about TLS itself
for those of you who are
not familiar with it.
TLS is the standard
protocol that's
used to provide
end-to-end communication
security over the internet.
If you think of an
HTTPS server, it's
simply an HTTP server that also
uses a TLS secured connection.
Now, if you're not familiar
with the acronym TLS,
you may be familiar with
something called SSL or Secure
Sockets Layer.
SSL was the predecessor to
TLS, and it was replaced by TLS
back in 1999.
However, because there is a
popular implementation called
OpenSSL for TLS, a lot
of people are still
more familiar with the term SSL.
What we're going to do
in this presentation
is walk through the
handshake for TLS 1.2.
This is the most widely deployed
version and the one used
in today's IoT implementations.
This handshake will show how
various security mechanisms
are used that we've discussed
earlier in the presentations.
Now, there is a more
recent TLS standard
called TLS 1.3 that
came out in late 2018.
It does optimize the
handshakes, so the handshake
is a little bit different, but
the same security principles
apply.
The other thing
that TLS 1.3 does
is it removes support
for many older ciphers
that have compromised security.
And if you reviewed some of the
earlier modules in this class,
you'll notice that
we specifically
talked about ciphers that
would be used in TLS 1.3
going forward.
However, TLS 1.3 hasn't
even been deployed yet
by major IoT services,
so we believe
discussing TLS
1.2 in more detail
is the preferred
option at this time.
Before we go into the
details of a TLS handshake,
I would like to make
one additional point.
If you search for
explanations of TLS handshakes
on the internet,
you'll typically
find ones that discuss only
server-side authentication.
This is because when
a browser connects
to a large public website,
like Google or Facebook,
those websites don't care
about who is connecting,
and therefore, there's no
need to authenticate them.
In an IoT network, the
situation is different.
You don't want any
old device that
will connect to your network.
You only want devices
that are authorized
to connect to your network
actually being connected.
Therefore, client-side
authentication is enforced,
and our discussion
on the TLS handshake
here will include
client-side authentication.
Let's start with a
very high-level view
of the different stages
of the handshake.
The first stage is known as
the client and server hellos.
There are no
cryptographic techniques
applied at that stage.
The purpose of this stage is
for the client and the server
to agree on which ciphers
they'll actually be using,
and also to exchange
the certificates
for mutual authentication.
The next phase is
authentication,
where the certificates are taken
and validated by both parties.
Obviously, this does involve
quite a bit of cryptography,
including asymmetric
encryption, digital signatures,
public key infrastructures,
and certificates.
The third phase is
key exchange where
a symmetric key is exchanged
between the two parties.
To exchange this key,
asymmetric encryption
and digital signatures
are required.
And if you recall our
discussion in one of the earlier
modules about
Diffie-Hellman, you'll
probably recall that the
actual key is not exchanged.
The value is just in parallel
generated by both parties.
Finally, at the conclusion
of the handshake,
both parties switch to the
agreed symmetric encryption
cipher and the
key they have just
exchanged to begin
normal encrypted data
exchange via messages.
The first message sent,
which concludes a handshake,
is a hash of the
whole handshake,
so each party can check that
no attackers successfully
compromised the
communication at any point.
Now, let's start
walking through each
of these stages in more detail.
The first step in the handshake
is the client and server
hellos.
It's a client, ie,
the IoT endpoint
or initiate the connection
to the IoT service,
and it begins by sending
a TLS client hello.
This contains a list
of the supported cipher
suite in order of preference,
a list of the supported TLS
versions, and also,
a random byte string.
The IoT server will then respond
by selecting the cipher suite,
and it will select the
strongest possible from the list
presented to it in
the client hello.
It'll then select the
latest version of TLS
that was available
in the client hello.
At that point, it will do a
couple of different things.
It will send a session
ID down to the client,
it will send its own
random byte string,
and it will send its
certificate chain along
with a request for the client
to send its certificate chain.
The random byte strings
we see exchanged here
will be used later to compute
the shared symmetric encryption
key.
Before we go on to talk about
the next step in the TLS
handshake, I'd like to explain
the actual cipher suite
strings in more detail as
it's often confusing when
you actually start looking
at the TLS API calls
as to what's happening.
I've given the example here of
a typical TLS 1.2 cipher suite
string, and you'll see it
base he has three components.
On the left-hand
side, the ECDHE_ECDSA
refers to the key
exchange algorithm that's
going to be used to share
the symmetric session
key between the
client and the server,
and then also refers to
the digital signature
algorithm that'll be
used to help authenticate
the key exchange.
The next part of the
string, WITHAES_256_GCM,
refers to the symmetric
cipher that'll
be used for encrypted
communication
once the secure
connection is established.
So AES 256 is the
symmetric cipher, then
the MAC or tag for
the message that's
used to authenticate each
message in the stream
is specified here by
GCM, Galois/Counter Mode.
Then finally, we have the
actual hash function, also
referred as a pseudo
random function,
and that can be used
in a number of ways.
It's used by ECDHE
during key generation,
and it's also used by DSA to
generate digital signatures.
Finally, if you're using a
different type of MAC function,
GCM does not need a hash, but
there are other MAC functions
that do require a hash.
If you selected one of those,
then it would use SHA_384 here
to help generate the MACs.
One thing you may have noticed
is that none of the ciphers
are associated with the
certification authentication.
And if you recall, a certificate
includes the information
on which cipher should be used
for its digital signature,
so therefore, that's independent
of the cipher suite list.
The next stage in
the TLS handshake
that follows the client
and server hellos
is authentication, where
the client and the server
authenticate each other.
We're just going to cover the
server being authenticated
by the client since the server
follows the same process when
authenticating the client.
The authentication
process starts when
the server sends the client--
which is a term we'll use
here for the IoT device--
its certification chain.
The client will then validate
the certificate change
and will need to
have the trusted root
certificate installed on it
to complete the validation.
As we pointed out
earlier, this might
be in a certificate store for
a more memory-rich client,
or it may have specifically been
loaded into memory for clients
with limited amounts
of on-chip memory.
Once it's checked the
certificate chain,
the next thing it does is look
at the certificate expiration.
It compares the expiration
date versus the current date
and time, which it fetches
via an NTP service,
such as one operated by Google.
If the certificate is not
expired, at that point,
it can just simply complete
the authentication.
However, in some
cases, it made do
something called checking
for a certificate revocation.
The certificate that
the service sent
may subsequently have been
found to have been compromised.
To double check this, the
client needs revocation status.
You can either go out and
request this over the internet,
but more commonly, there's a
technique called OSCP stapling,
where the IoT server will
have already provided
the revocation status stapled to
the initial certificate chain.
The client can then check if
the certificate's been revoked.
If it has not, it can assume
the certificate is valid
and then proceed with the
rest of the communication.
Following these three
steps, the client
can now be sure that the server
certificate is, in fact, valid
for use.
There is an additional
step that needs to be done.
We'll cover this in
the next section.
But essentially, the
client at this point
doesn't know if the server
owns the private key associated
with the public key
in the certificate.
So in the next step,
what will be done
is for the server to encrypt
some data that the client knows
about with its private
key, send it to the client,
the client will then
decrypt it and match it
with its version of the
data, and if these match,
it now knows that the
server does, in fact,
own the private key associated
with the certificate
and can be trusted.
As I mentioned at the
start of the slide,
when a server
authenticates a client,
the steps are
essentially the same.
The one potential difference
is that an IoT server may well
have a list of
client certificates
that are valid for
its IoT devices,
and it will likely check against
that valid certificate list
rather than explicitly checking
for revocation, for example.
Once the certificates
have been authenticated,
the next step is key exchange.
And to remind you
what we're doing here
is where we're going
to actually calculate
the shared symmetric key
that both parties will
use for the main part
of the communication
throughout the rest
of the session.
The key exchange begins with
the send server key exchange
message.
This sends over the server
Diffie-Hellman parameters.
In addition, if we go back
to the previous slide,
I discussed how the
client, for example,
needed to be sure that
the server actually
owned the private key that was
associated with the public key
sent in the server certificate.
That's done in the send
server key exchange message.
So the server
generates a signature
from the previous
handshake traffic,
and obviously, that signature
is simply a encrypted--
[AUDIO OUT]
--hash the previous
handshake traffic.
When the client receives
that, it can then
take the public key and
the server certificate
it received, decrypt
the hash, and then
compare it with the
hash it generates itself
with the previous
handshake mass--
the previous handshake
message traffic.
If these match
up, it then proves
the server owns a private key.
At that point, the
client will then
send its key exchange message,
which, of course, will include
a handshake of the
previous traffic
as well in the case of
client side authentication,
and its Diffie-Hellman
parameters.
If you're not familiar
with Diffie-Hellman,
please refer to the previous
module on certificates
and the module before that on
asymmetric encryption and this
will explain how
Diffie-Hellman works
in a little bit more detail.
So at this point,
both sides have
the Diffie-Hellman parameters.
And if you recall, in the
client and server hellos,
they both exchanged
random byte strings.
At this point, both parties
can independently calculate
a shared secret key using
the Diffie-Hellman parameters
and the random byte string they
receive from the other party.
There are several
stages involved in this,
and I'm not going to
get into those stages.
They involve pretty
complex mathematics.
But the result of
the key calculation
is the end of that
process, both sides
have independently come to the
same shared secret key value
to begin communication
using symmetric encryption.
At that point, the client sends
a client change cipher message.
The change cipher message
will tell the server
to change to the previously
agreed symmetric encryption
protocol, such as AES 256.
In addition, the
client finish message
includes a hash of the
previous handshake messages.
The server can
compare this to a hash
of its record of the
previous handshake messages
to make sure that
no attacks occurred
at any stage of the handshake.
At that point, the
server obviously
changes to using the symmetric
encryption protocol agreed
for the rest of the session, and
it sends back its change cipher
message and it's
server finish message
so the client can,
again, verify that there
were no successful attacks
during the exchange.
Once the TLS
handshake is complete,
the session can then proceed
with message exchange
between the client and server.
This is a very
straightforward process.
The client will simply encrypt a
message with the shared session
key and send it to the
server, which then decrypts it
with the shared session key,
and vice versa for messages
from the server to the client.
A couple of points to
make are the session key
is not stored
permanently, and that's
one of the advantages of
the ephemeral Diffie-Hellman
implementation that's
now standardized for TLS.
It means a new session
key will be created
the next time the client
and the server connect,
and that means that
subsequently getting
hold of the key
for a later session
does not enable you to
decrypt earlier sessions you
may have recorded.
And again, if we go back to our
discussion a couple of modules
ago about symmetric encryption,
symmetric encryption includes
a Message Authentication
Code, or MAC,
which is used in each message
to make sure that an individual
message cannot be altered or
tampered with by a third party.
So that concludes the discussion
about the TLS handshake.
Now we're going to move on
to talk about a certificate
signing request.
The use case we're going to
cover for a Certificate Signing
Request, which we're
going to abbreviate
to CSR in the rest
of the section,
is how you use one to join
an IoT device network.
Earlier in this series,
we've pointed out
how IoT device
networks are closed.
They're not open
servers like Google,
Facebook allows any
client to connect.
They only want authorized
IoT endpoint devices
to connect to them.
And to enforce this,
the IoT endpoint device
must have some type of
security credential, which
will typically be a certificate
if the IoT network is
using something standard
like TLS authentication.
If the IoT device has its
own public private key pair,
it's possible for the IoT
device to generate a CSR
and get the certificate
delivered at run-time rather
than having to burn it in
directly in the factory.
The advantage of getting
a certificate at run-time
is reduced costs because
managing certificates
and the associated private
keys during manufacturing
means you either need an
expensive, secure manufacturing
location, or you need to
have a third party create
a series of secure
elements that contain
pre-burnt certificates
that can then be used
at a low-cost manufacturer.
Either of these
approaches adds cost,
and therefore, it's much
more desirable to add
the certificate during, for
example, product installation.
However, the way CSRs
work means that you
have to do a little bit
more than just a simple CSR
to guarantee only authorized
devices can join the network.
And to do this, it's very
useful if the IoT device also
has a unique identity that
can be used with the keypad
to help verify its identity.
To enable the device identity
to be confirmed prior
to issuing the CSR,
it's necessary to have
a database that matches a device
ID with the public key value
that the device will
have in the certificate.
Each IoT endpoint device will
need to have a unique identity.
This may be an immutable
identity that's
already present on the device,
either in a secure element,
or in the MCU itself,
or it could simply
be added as a label on the
box the device ships in.
In the case of the unique
identity being on a label,
it will be necessary for there
to be a phone app for the user
to enter the unique device
identity during installation
so that device can use it.
The IoT device vendor
will need to create
a database that stores
both this identity
and the associated
public key that is
stored on the endpoint device.
This database can come
from a couple of sources.
Semiconductor vendors
who provide secure
wireless MCUs or
secure elements may
provide a whitelist that
contains the public keys
and associated identities.
This may come with certain
volume requirements,
such as a minimum
of 2,000 devices.
Another approach is simply
to generate the database
during tests.
For example, when the
IoT endpoint device
is being tested,
it can be booted up
and some code can
be used to extract
the public key and
the identity, and then
it can then be stored
in a database that can
be used for future reference.
Now we've described how
the actual database will
be used to verify the IoT
device identities is created,
let's actually look at the
process of the CSR being
generated, and then the
provisioning service verifying
it's the legitimate CSR.
So if you look at
this diagram here,
we'll see we have the
IoT endpoint device,
and the user will connect
that up to their home network
and begin the installation.
Once the IoT endpoint device
is connected successfully
to the Wi-Fi home network,
it can now generate and sign
the CSR, and this CSR will
include the identity that's
unique to the endpoint
device, and also will
include the public key.
This CSR is now sent
to the provisioning
server, which we've called
the registration server here.
The goal of the
registration server
is to validate the
device's identity,
and it does that by referring
to the identity database
we described in
the previous slide.
So you'll see here that the
CSR comes in, the provisioning
service will extract
that identity
from the CSR and the public
key and then compare it
to the entry in the database.
If there is a matching
database entry that
has the device ID with the
same associated public key,
it knows it's a authorized
device, and at that point,
it can then pass the CSR onto
the certificate authority
server.
The certificate authority
server will now then
issue the client's certificate
back to the IoT endpoint
and that will then
store that certificate.
It should store it in a secure
manner so it cannot be accessed
by unauthorized parties.
Now that the IoT endpoint
device has the client side
certificate, it can now
simply open a TLS connection
to the IoT network, which,
of course, requires client
authentication, and then
it then simply passes up
the client's certificate during
the authentication process,
and the IoT service
will permit the device
onto the IoT network.
Shall see with this approach
that there was no need
to actually preprogram the
certificate into the IoT
endpoint device.
It simply went out and got
it during installation.
And this greatly simplifies
the production process
for IoT devices.
A third common application that
involves use of cryptography
is secure OTA updates.
OTA stands Over-The-Air, and can
really be effectively regarded
as remote updates.
Virtually every single connected
and embedded application
is going to want to
do remote updates.
There are several
reasons why is this so.
First, it's much cheaper to
remotely patch bugs or security
vulnerabilities in an embedded
application via a network
connection than have
technicians physically upgrade
each individual system.
Secondly, you're going
to want a cheap way
to replace expired or
revoked certificates, which
again, feeds back to
improving the security
of connected devices.
Then finally, it
may be a good way
to boost business by
adding a new service
to an embedded application that
generates a new revenue stream.
So the ability to do
OTA or remote updates
is extremely critical for
any modern IoT application.
However, security
is very important,
because since the OTA
mechanism is actually
downloading a new image,
if an attacker can subvert
that mechanism,
they can therefore
take control of the device
by installing malware.
So cryptography, obviously,
has a key role to play in OTA.
Now, unlike secure
connectivity where
there's standards like
TLS that prescribe
how to perform a
secure connection,
there is no specific protocol
that governs an OTA process.
So what we're going to
do here is walk through
an implementation
of an OTA process
that does deliver security.
Now, of course, secure OTA
requires a secure TLS-enabled
connection, but in
addition, it also
requires another certificate
called a code signing
certificate that's used
to authenticate the image.
Before we get into the
specific steps of performing
a secure OTA update, there's
a couple of security risks
I'd like to highlight.
One is fairly obvious.
Since the IoT device endpoint's
expecting a new image,
an attacker can try to
substitute their own image
so they can perform a malware
takeover of the device.
The second form of attack is
called a downgrade attack.
In this case, since
the OTA device
is looking for a
signed image, it's
not possible to substitute
a random malware
image to do the takeover.
However, if the attacker has
obtained an earlier OTA update
image with a known
security vulnerability,
they can send the device
that image in the hope
they can downgrade the device to
this older version of software
that can then be exploited
by another form of an attack.
So how do we go about countering
these security threats?
The first step is to create
a digital signature that we
can use to sign the image.
To do that, we would simply
take the OTA update image,
create a hash,
then we encrypt it
using the private key of
the code signing certificate
to create the signature.
By signing the image, we make
it impossible for an attacker
to pass malware via
the OTA mechanism
and then have that malware
accepted as an upgrade.
Now, of course, simply
signing the image
doesn't address the
downgrade attack approach.
To counter downgrade attacks,
it's useful to add metadata.
Obviously, one extremely
important piece of metadata
is the actual version
of the software image.
So if we append some
metadata to the image
prior to creating the
signature, at that point,
we'll have a version
associated with the image which
will prevent a downgrade
attack from happening.
It's also worth including
other types of metadata,
such as the applicable
product part numbers.
These are helpful to prevent
reliability problems in the OTA
process that can end up
bricking the endpoint.
And we'll discuss reliability
in a little bit more detail
later in the OTA discussion.
Once assigned OTA images
available on the OTA update
server, the next step is
to have the IoT endpoint
device download it and
then authenticate it.
On the IoT endpoint device,
there will be an OTA agent,
and this will
periodically monitor
to detect if there is
a new update available.
If a new update is
available, the OTA agent
will establish a
secure connection
to the OTA update server using
TLS, although in some cases,
the OTA agent may simply use
the existing telemetry channel
to perform the download.
It then downloads the image
and metadata and signature
into temporary files.
The IoT endpoint device will
already have the public key
from the code signing
certificate burnt into it
during production.
It uses that public
key to extract the hash
in the digital signature.
It then takes the
downloaded image
and generates a hash
for that and compares it
to the hash in the signature.
If these match, it knows
the image is valid.
At that point, it will check
any metadata, such as version
numbers, and if the version
number of the downloaded image
is later than the one that's
already on the IoT endpoint
device, it knows it
can safely upgrade
and is not suffering
from a downgrade attack.
The final step is to
boot the new OTA image.
The booting process should
incorporate a number of checks
to ensure that it works
reliably and securely.
The bootloader should be secure.
By a secure bootloader,
I mean the bootloader
should check the
signature of the image
to authenticate that it comes
from the device provider.
While, of course, we've already
checked the image signature
when we did the download,
having the bootloader also check
this is important,
because it's conceivable
that physical
attacks on the device
might attempt to replace
the image in the device
with a malware
image by inserting,
for example, a new memory chip.
And in that case, a secure
boot would prevent this
from being successful.
In addition to checking
the image is signed,
you also need to be
concerned about reliability.
You certainly don't want the OTA
boot process to hang the device
and render it
non-functional to the user.
So a few procedures should
be done to prevent this.
One is that device should
have enough memory that you
can keep the prior image
version available on the device,
and if the booting of
the new image fails,
you need to be able
to revert back.
To prevent a hang
from happening,
you just set a watchdog
timer and that will time out,
so if you do hang, the
watchdog will trigger,
and then you can then, again,
revert to the previous image.
So if we look and
see what happens her,
the bootloader will
check the signature
and then set various
flags for the watchdog.
It will then boot the OTA
image, run through a self-test,
and if the self-test fails, or
the image hangs, or you have,
for example, run out of
battery and the device fails,
all of these will simply
result in you rebooting
the previous old
image that you know
works the next time around.
If, of course, you successfully
pass the tests, that point,
you'll stop the
watchdog and then
set the OTA image to be the new
image that the device always
boots from.
It should be clear by
now that certificates
are a key element in
providing secure connectivity
between an IoT endpoint
device and the IoT servers.
With that in mind, I'd like
to summarize exactly how
many certificates are
needed down on an IoT device
to security connect and
perform secure OTA operations.
This particular walkthrough will
be based on a Texas Instruments
CC3235 Wi-Fi MCU.
It's an ARM Cortex M-based MCU
with a dedicated Wi-Fi network
and security processor.
One important point is that
the trusted root catalog that
is programmed into the
CC3235 only contains
hashes of each certificate.
This is because the
CC3235 is an MCU
with limited on-chip
memory, and it's not
possible to load every full
certificate into memory
without taking up an
inordinate amount of space.
When establishing a
secure TLS connection,
the first action the
device will need to do
is to authenticate
the IoT server.
IoT server will send down
its certification chain.
The CC3235 will need to
contain the trusted root
for the service certificate.
That means the IoT
device manufacturer
must preprogram the trusted root
certificate into the device.
Because we're dealing
with a closed network,
the IoT device manufacturer
will know in advance
the trusted root required
for the server certificate.
The IoT device will use the
hash in its trusted root store
to verify that the
trusted root programmed
into the device for the service
certificate is, in fact, valid.
The next step in establishing
a secure TLS connection
between the IoT
device and its server
will be for the server to
authenticate the IoT endpoint
device.
This requires that
the IoT endpoint
device can send a copy of its
clients certificate chain.
The certificate
chain will obviously
contain the TLS and entity
certificate and whatever
intermediate root certificates
were used in issuing that end
entity certificate.
Because the server will have a
operating system like Windows
or Linux, its trusted
root store will certainly
contain the full
trusted root certificate
to complete the client's
certificate validation.
For the IoT endpoint
device to be
able to authenticate a
signed OTA update image,
it must be able to validate
the code signing certificate.
In the case of the CC3235,
there is a requirement
of the complete code
signing certificate chain be
present for the image
to be authenticated.
So in this case, we need to have
the code signing certificate
chain, including
any intermediates,
and the trusted root for
the code signing certificate
to be all present
on the end device.
It should be stressed,
however, that many IoT device
vendors are happy
with simply putting
the public key associated
with the code signing
certificate on the IoT
endpoint and just using
that, not doing a full
certificate chain validation.
Remember that OTA not have
any formal protocol associated
with it, unlike TLS,
so therefore, there
is flexibility in how
you implement this.
So let's summarize how many
certificates are needed.
We need two trusted
root certificates.
One of these is the trusted root
for the TLS service certificate
so we can do the authentication
of the server certificate.
We need a complete TLS client
certificate chain, but not
its trusted root since that
will be stored on the actual IoT
server that does the
authentication of the client.
For a device like
the CC3235 that
wants to see a complete code
signing certificate chain,
that whole chain,
including the trusted root,
needs to be also on the device.
However, since there's not a
standard protocol enforcing
this requirement, on
some other devices,
you may be able to
simply just to put
in the public key for the
code signing certificate
to authenticate any images
downloaded for update purposes.
In this module, we walked
through several use cases
where encryption is used
in common embedded software
applications.
The first of these
was TLS, which
is the standard internet
security protocol.
We went through the
handshake and showed
multiple use cases of asymmetric
and symmetric encryption
and how they're used to
establish and maintain
a secure connection.
We then look the OTA
downloads and how encryption
helps with signing
images to make sure
that only authenticated images
are accepted by the IoT device.
We also looked at a
certificate signing request
and how that can be combined
with a unique device identity
to create a secure
run-time provisioning
implementation that
avoids the need
to have certificates
preprogrammed
into embedded devices
in production.
We then finished by recapping
how many certificates you
actually need on an
IoT device to make sure
that you have a clear
understanding of what
is required for secure
connectivity and OTA.
This is the last module
in the understanding
secure connectivity
training series.
If you stay with us
with the next slide,
you'll see a number of
options where you can actually
delve into hands-on training
using a TI Wi-Fi MCU.
Thank you for taking
the time to listen
to this series of
training modules.
I hope it was helpful
in understanding
security-related technology.
At some point,
it's likely you'll
want to do some actual
software development
of a secure connected
application.
I've put a few
links here to enable
you to get the appropriate
software and valuation
modules to develop secure
connected applications on a TI
SimpleLink Wi-Fi device.
We have an extensive set of
hands-on training modules
called SimpleLink Academy, and
if you go there and select,
you'll see a number
of examples that
deal with secure
connectivity, secure storage,
and cryptography.
