Securing IoT Connected Device Applications

Ian Massingham

Recorded at GOTO 2016


Get notified about Ian Massingham

Sign up to a email when Ian Massingham publishes a new video

[Music]
good morning I was curious how many
people would come along to this session
cuz IOT is still quite a I wouldn't say
a niche but still quite especially
subject there aren't actually of the
total number of developers that are out
there though I'm actually that many
developed developers working in the IOT
domain and then InfoSec in IOT is like a
knee Shiv and niche so relatively small
subset of people that you guys obviously
in that final intersection of those two
Venn diagrams that overlap with each
other so thanks for coming to the
session and my name is Ian I lead
technology evangelism for AWS in Europe
Middle East and Africa region so we're
all about trying to help developers
become productive in use of AWS services
probably the first question you're
asking yourself is why is somebody from
from Amazon Web Services up here talking
about IOT what do we have to do with IOT
well there's a couple of things firstly
AWS customers are being using the AWS
cloud to build connected device
applications for a long time three good
examples of that would be tile do you
know about tile have you seen them you
I'll show you
so they've got a little Bluetooth Low
Energy tracking token that you can
attach to a device like a set of keys or
a motorcycle or a piece of luggage and
then that pairs up with a Bluetooth
receiver app that goes on your phone and
you can find your device anywhere in the
world
it will record the last known location
of the item that the tile is attached to
that's how they started they've extended
that now and you can actually buy
luggage other items of equipment that
already have tile tokens pre embedded
within them sort of like part of the
construction of the product and they
provide a value-added service to other
manufacturers that want to track their
allow their customers to track their
items anywhere in the world that's built
on AWS then we've got so nós which a lot
of you be more familiar with I'm sure
the connected audio product and we also
have regulated examples so Philips
healthcare was a little bit surprised
than the kina actually when the keynote
speaker was talking about difficulties
with managing compliance in the cloud
Philips Healthcare started connecting
their medical imaging devices to AWS
about three years ago and if you go into
a hospital in North America now and have
an x-ray or a cat scan there's a good
chance that the data from that scan
scanning activity will be stored on AWS
they directly attached they're attached
connect their devices to the cloud using
our secure api's and they stream their
imaging data straight out of their x-ray
systems directly into AWS and then we
protect that with HIPAA compliant
information security controls to make
sure that only authorized clinicians can
access that imaging data and see it's
part of your EPR your electronic patient
record so customers using AWS services
to build stuff like that for a long time
and then in 2015
AWS reinvent actually more or less this
time last year we announced a specific
service for IOT which is a managed
platform for building IOT apps so this
is a AWS IOT I'm going to return and
talk a little bit about that later on
but basically the intent really was just
to simplify down the ingress and device
management process for developers that
wanted to connect
low powered and lightweight connected
devices to the cloud in order to build
applications of this type in the future
so we've got some service components
that are intended intended to simplify
later
really only in the context of how we've
implemented some of the guidance that
I'm going to give you now about how to
secure this kind of apps so everything
that I'm going to talk about from now on
you could build yourself using your own
engineering skills assembling components
or you could use many services like like
AWS to deliver so security and the
Internet of Things when I was asked to
do this talk I was thinking to myself
how am I going to contextualize this how
am I going to make this this topic area
real for the audience and then
fortunately this happened like two weeks
ago okay so now I don't have a problem
everybody knows about security IOT
security you know about this right this
is the attack on din on the global DNS
service provided din described in the
presses as yellow pages for the internet
which I thought was quite a good good
articulation of what DNS is but of
course what happened here is some bad
guys hijacked a lot of connected device
infrastructure and they used that as a
botnet to deliver an attack pattern
against a critical piece of Internet
infrastructure and it had a big input
impact on some of the largest servers
services on the internet so there's no
need really for me to try and paint a
picture of what the potential risks are
if you are building connected device
applications you don't take care of
security bad things can happen again
will return to precisely how those bad
things can happen can happen later so
much so that it's become a joke now so
you know why am i hacker $100 or well
reversed my motor and blow dirt all over
this place or excuse us while we
participate in a DDoS attack so you know
it said now a meme minute own right the
internet of ransomware things is the
title of this this cartoon very nice so
how does something like that happen how
can an attacker take control of a large
number of connected devices in order to
use them to to stage an attack or to do
other things well in theory everything
safe right Bob lives behind a firewall
and Bobby's safe bob has a stapler and
Bob wants to know what's happening with
his stapler so he has a video camera
that uses for monitoring his stapler
and bob has a browser-based app that
allows him to connect to his video
camera and see whether his significant
others moved his stapler make sense with
me now Bob wants to go out okay of his
house but he still wants to monitor the
status of his stapler so it gets the
instruction book for his IP camera and
in his instruction book it tells him to
find the address of his IP camera on his
local network and then make a change to
his firewall okay and when he does that
he exposes his local camera she's on his
local network to the Internet it's
called port forwarding you guys will
know all about it if you're an InfoSec
so what's he done there well he's made
it possible for him to go out onto the
internet with his phone forget about all
this stuff behind his firewall and he
can now access his camera and make sure
that his stapler is safe while he's out
in the world okay but he's made a
critical mistake here hasn't he it
exposed that device to other people to
bad guys that might be out out there
those bad guys have equipped with
helpful tools like showed under IO this
is a tool for searching for patterns on
connected devices so you can you can
look for four webcams that are
inappropriately secured you can look for
four DVRs or PVR's that might be exposed
publicly you can look for all sorts of
infrastructure which has default
security settings where the admin
password is password and the admin
username is admin okay and you can take
that and you can of course automate that
process so this is your control system
and then you can take control of Bob's
camera and if there's an application
vulnerability on Bob's camera you can
own it you can run software on it you
can view Bob stapler you can do whatever
you want because he's exposed that
device to the public Internet and the
attackers can access it in exactly the
same way that he can okay so if that
device is not secure they can take
advantage of vulnerabilities and they
can do things with those vulnerabilities
now the problem is you know there's not
just Bob
this is how I explain to my kids where
botnets come from by the way and they
asked me that question sir daddy where
do botnets come from they come from
individuals wanting to achieve certain
outcomes and following simple
instructions that have been given to
them by people that unfortunately choose
not to adequately maintain those
connected devices that don't adequately
maintain the software that's on them and
the result of that is you can get access
to large fleets of connected devices
which in adequately secured okay so
that's really in simple terms the main
problem with with IOT security of course
it doesn't have to be like that there
are other ways that you can build
applications like that so here's the the
right way to do it everything looks the
same
Bob can still view his camera on his
local network and he still uses that
address to do so but when he goes out
onto the web onto the internet and takes
his mobile doesn't communicate directly
with the camera it has to communicate
as a set of services and that control
plane well a camera communicates with
the control plane so the camera only
ever communicates outbound we're now
inbound connections that go through the
firewall back to the device okay this is
the correct pattern to use for building
this kind of application what's the
difference between this and the other
pattern from the device manufacturers
perspective well you have to run this
control plane infrastructure the device
manufacturer has to be responsible for
that but obviously there's a cost
associated associated with that so if
your objective is to deliver very very
low cost devices and maybe you're only
revenue model is to sell those devices
to customers and you get a one-off
payment each time they buy one probably
as a device manufacturer you're not
highly motivated to engage in best
practices you're not motivated to build
applications that are secure you've
motivated to build applications that
have the lowest cost profile and the way
to do that of course is not to have the
control plane but simply to expose the
device directly to the Internet and
allow that direct control okay so that's
a little bit about in very very simple
terms why these issues arise and also
what the ideal architecture is to avoid
them
and we're going to talk a little bit
more now about this just to give you a
little bit more flavor so now the camera
and this particular attack pattern where
the camera or rather a fleet of mixed
devices some of which were cameras as
used to launch an attack is actually a
typical for connected device
applications okay
most of the connected device
applications that we engage with
customers to help them build are much
more lightweight that the devices
themselves aren't fully featured
machines that when operating systems and
web servers they are much more
lightweight in nature okay they're
constrained really and microcontrollers
and very small arm CPUs are very common
in this particular use case okay so you
often don't have much power on the
device you're also working in
constrained environments those
ways actually give you an example we
have one customer called Telenor
connection you'll know them the IOT
business unit of kellan or which is the
former state operator in Norway and they
provide industrial and agricultural IOT
solutions one of their products enables
farmers to connect livestock to the
internet so the sheep or cows wear a
collar a little bit like an agricultural
version of a Fitbit the collar has a
temperature sensor and an RFID locator
in it the temperature sensor is used to
provide periodic updates about the
health of the animals so is the animal
abnormally hot and if it is they'll send
out a vet the veterinary will go out
into the herd of animals he'll take an
RFID locator with him and when he gets
close to the animal with the right
serial number the detector will ping so
he can find the affected animal in the
large herd of animals and he can treat
it there's quite a lot of constraints
here the the colors themselves need to
be weatherproof so you don't want to be
tampering with them right which means
you don't want to have to open them up
frequently because if you do you
probably break the waterproofing which
means you want them to be low power so
you can leave them out in the field for
a long period of time without having to
retrieve them and replace them or
update the power supply in them because
they're low-power this means that they
have to have very small CPUs and very
lightweight radios in them so this means
that they use line-of-sight radio
systems which is deployed on buildings
around the farms around the farm
infrastructure and that's how they get
the data off the animals to a gateway
and then send that data to the cloud to
the endpoints that they use to build
that service so there's quite a lot of
constraints in that environment very
small CPUs very limited radio capability
but the benefit of that is the devices
are automatically behind a gateway so
the devices themselves don't have any IP
connectivity they don't communicate with
IP from the device to the radio they
communicate with a proprietary radio
protocol and the radio gateway then
packages up the data packets into an IP
packet with the right format and sends
them off off to the end point so these
constraints can also actually be
beneficial from a security perspective
those endpoints cannot be attacked the
Gateway could be attacked but the
endpoints themselves cannot be attacked
by an attacker there's no way for them
to get to them
remote locations variable physical
security already I've talked about quite
a few different segments haven't I and I
guess some of these segments are just
not attractive to an attacker that
agricultural example I just talked about
there it's not attractive to an attacker
there's no value in getting access to
that data
and there's really very little for an
attacker to take control of and make use
of for their own purposes just that
gateway endpoint which might be exposed
so you can also do some modeling nation
here and work out which areas of your
application may and may not be
interesting to people that want to
attack it also you've got variable
criticality of course as well and I've
already hinted there that the first step
towards building these kinds of
applications is to think about threat
models so commonly applied threat models
like stride is one so this is a model
that was developed by Microsoft it
involves looking at areas such as
spoofing tampering risk repudiation or
change risk information disclosure so
what's the potential risk of a privacy
breach or data leak
and then issues such as denial of
service or elevation of privileges and
you can use an assessment of the same
type with an IOT application just as you
might do with any other type of app okay
and when thinking about these
assessments you need to do some of the
stuff that I just described so think
about how attractive this particular
application or services to attackers
think about what the potential
probabilities and the consequences of
bad things happening might be so if
someone hijacks my egg Racal system what
are the consequences may find out later
than I want that some of my sheep Arale
and maybe they'll die okay if somebody
hijacks even that medical system that I
was talking about earlier if someone was
able to circumvent that they might get
access to cut to patients EPR through
electronic patient records there's a
regulator which oversees the protection
of that data the care provider could be
hit with quite a heavy fine and
reputational damage as a result of that
information leaking or it being being
disclosed that that information had been
obtained by a third party so you need to
consider these kind of issues when
you're thinking about information
security and application security for
IOT apps okay just as you would do for
for any other kind of application that
you build of course there's another
component here which is to do with with
safety so we're talking about things
things aren't some sort of abstract
logical construct that exists only
within software they're physical devices
and they can have physical consequences
in the real world I was looking for more
source material last night and I heard
about an apartment complex in Finland
where a building management system had
been attacked okay and the implications
of that were that they couldn't heat or
cool the building for a 48 hour period
now probably it's a Western country okay
probably those people have got other
alternatives that they can go to for
heating but it's still a pretty cold
place to be at this time of year okay
it's just one example of a pretty low
end spectrum continuum of different
consequences that might occur
if somebody is able to take control of
physical devices or affect the operation
of physical devices and then we get into
more safety critical systems like
self-driving cars industrial control
systems large-scale transportation
operations that we might want to
automate so there's a lot of safety
factors here and essentially what can
happen if the system is not adequately
protected is you can have bad guys that
take control of endpoints may be
injecting malicious data into the system
and that can cause really bad things to
happen in the real world so there are
definitely definitely threats that need
to be considered here so the main part
of the talk how can we defend against
this you know what sort of steps can we
take architectural II and with technical
controls to prevent some of these things
happening that I've talked about and
these are the three broad areas that
we're going to talk about so we're going
to talk about secure communication with
things how do we prevent tampering how
do we protect regulated or valuable data
that might be flowing from things to our
service endpoints and do that in a way
which prevents tampering pretend
prevents eavesdropping and prevents
repudiation we're going to talk about
identity how do we know what we're
communicating with how do we know that
the entity or principle that we're
communicating with is the intended
endpoint for our traffic that we're
going to send to it and then we're going
to talk about fine-grained authorization
so we want to gather data from our
things and our analytics of a
visualization we want to control or take
actions or change state of our devices
so how do we ensure that the logic that
drives those activities drives that
persistent storage of data drives those
state changes is it self protected and
we're able to interface with the backend
of this infrastructure in a in a way
which is trusted in secure and then
lastly how do we go about building
services so first thing we're gonna look
at is is secure communications and this
is an context or an environment where
you need uni-directional security is
acceptable okay so for traditional
tls/ssl so
we're communicating with websites let's
say let's say we're a retailer let's say
we're Amazon is it important for us to
digitally verify the identity of people
that connect to our services we're going
to identity verify that identity in
another way we're going to verify their
identity through e-mail verification and
we're going to verify their identity
through the most important way for us
before we ship any inventory to them
we're going to take payment aren't we
okay so we have verification of identity
that takes place above the transport
layer in the cases of actually most web
applications we have verification of
identity it takes place above the
transport layer but if I'm a customer
say I'm dropping onto amazon.com to buy
this week I bought my kids some paper
they do a lot of drawing so I'm buying
paper on amazon.com is it important to
me that I'm giving my credit card
details and my personal data to someone
whose very identity that I can verify of
course it is so in this model you have
unidirectional identity proof okay and
of course the way we do that is with
digital certificates okay so a digital
certificate contains two things it
contains well three things actually an
identity statement so who is the
principal who is the entity that I'm
connecting to it contains their public
key okay so so that I can encrypt data
with that key and send it to them and
then they can use a symmetric keys to
decrypt that data and read it and it
also includes cryptographic proof that
they hold the private key and their
identity is being verified this is what
a certificate authority does a CA okay
so they will sign a digital certificate
verifying ID of the party that holds the
certificate and also through a
cryptographic proof verifying that the
party holds both the public and private
key out of that key pair okay so that's
what this is who knows what happens for
keys over here we've tls/ssl anybody
know what happens when I connect I don't
have a key do I so how do I get a public
and private key pair to enable me to
secure communications across this Chan
anyone no yeah no you have session keys
actually so each time you connect to a
new website or establish a new session
to a website you generate randomly at
that point a public/private key pair
which is good for that one session okay
at the end of that session those keys
are discarded okay and then when you
restart the next session you do the same
thing again you generate a session key
for that particular session because he
doesn't care who I am all he cares I
just send my public key across using
this public key to encrypt it so it goes
across encrypted you decrypt it with his
private key and then for data that he
sends back he uses that public key to
encrypt traffic and I hold my private
key never disclosing it and I can
decrypt the traffic when it comes back
to my browser that's how the flow works
in in tls/ssl and actually that's why CD
ends content distribution networks and
distributed endpoints offer such a
performance increment for
cryptographically protected traffic the
process of doing the session sale and
the key generation in key exchange
actually involves quite a lot of
transactions it involves about 20
establish this secure link in this model
so it's intensive in terms of
computational activity on the client
start to generate the keys it's also
intensive in terms of network traffic
because I'm handshaking then I'm
exchanging the keys and finally after
those 20 transactions we can start to
send traffic in a secure way okay this
is why content distribution networks
like how a cloud front another content
distribution networks offer such a
performance boost for encrypted traffic
because they take that negotiation and
move it much nearer to the client they
reduced latency and if you're cutting 10
milliseconds off 20 transactions you've
taken a fifth of a second off the
session setup time okay so so web
related topic but it's important you
understand how this works it's not good
enough IOT okay the reason that it's not
good enough IOT is twofold first of all
we talked about constrained environments
and I just talked about session key
setup and how computationally intensive
it was computation cost battery okay so
if I've got my lightweight sealed IOT
device I don't want to be randomly
generating
long cryptographic keys each time I need
to perform a connection okay because
each time I do that I'm running the CPU
on my device to do so and as I run the
CPU for that activity and burning
battery okay so I want to have keys that
are static that only I have I don't have
to regenerate each time I make a
connection okay and it's also important
that the identity of the connecting
device is known okay otherwise I can
spoof potentially spoof my identity okay
or even connect anonymously to a service
endpoint this could be dangerous okay I
could send a piece of medical imaging
data that was purported to be about a
patient that it wasn't actually about
because I could forge a connection from
an untrusted endpoint injecting data
into the service and I could potentially
by doing that subvert the logic in the
service and have significant impact
right so I need to know who is
connecting to my service so with mutual
TLS or we have over here another digital
certificate this digital certificate is
uniquely associated with the device okay
and we have a pre generated public key
onto the device and once again ideally
unique to the device okay so when I make
a connection request the gateway
endpoint can verify my identity so it
knows who I am
okay it can associate a policy with the
identity permitting or allowing me to do
certain things in the platform that are
linked to the principle associated with
this digital certificate and also I have
no key generation activity out here I
can immediately encrypt data using this
public key and this guy can immediately
encrypt data using this public key and
send it back to me I will decrypt it
using my private key but there's never
been key generation or key exchange
activity such much more computationally
efficient and it uses much less network
bandwidth as well okay what make sense
good so we want that model we don't want
that model foot for IOT
now a public key cryptography options
asymmetric keys which is what we're
talking about here there were two
different broadly supported options for
asymmetric keys one of them is the RSA
key pair which you'll be familiar with
if you use SSH RSA key pair generation
machines is very common note that these
keys are quite long okay and length of
the key is correlated with the CPU
overhead the CPU cycles that are
required to perform cryptographic
graphic operations using that key
the longer the key the more CPU
horsepower is required to encrypt data
okay
symmetric keys where you use the same
key for encrypt and decrypt they're much
much shorter and they have a much lower
computational overhead for encrypting
data using them okay but that's no good
for our model because we want to have PK
I want to have public key infrastructure
we don't want to be able to we don't
want to use symmetric keys in this model
we want to use a symmetric keys so
there's another option which is called
ECC or elliptical curve cryptography
it's an alternative algorithm an
alternative set of ciphers that are
available for a public key crypto
provides a similar outcome to RSA where
we each have our public and private keys
and we can only decrypt data where we
hold the private key corresponding to
the public key that's been used to
encrypt it but the key size is much
smaller and you see here you can for a
2048 RSA key you only need 224 bits on
an ECC key for the equivalent level of
crypto strength okay so it's much more
lightweight for encryption and
decryption operations and if you can
build this into your IOT client
applications you're going to find it
much more battery efficient as a result
of that okay so 10 towards elliptical
curve cryptography and tend towards the
shorter key lens that that provides if
those are available to you and you can
build them into your applications and
software okay we support this in our
service there's a blog there which
describes actually some detail not only
about what the benefits are but also
we'll walk through of how to do key
generation for ECC using open SSL so if
you are interested
experimenting with elliptical curve
crypto it's actually quite a good primer
to help you get started with that okay
so that's on the device side okay but of
course the vast majority of IOT
applications don't consist solely of
machines talking to machines we want to
have human beings that can either
extract data or analytics and insights
from the data that we're getting from
our fleet of devices and a lot of cases
we want to be able to do stuff you know
I want to be able to make my tile ring
so that I can find my keys if they're in
a general area but I can't find them I
want to be able to control the
temperature on my hive or nest
thermostat from my phone right I want to
be able to do something with these
devices so we also have to be able to
communicate with non things we have to
be able to communicate with with wetware
with with human beings right so how do
we do that we implement that through
another set of API is which I'm going to
talk about later okay and over here we
are using the concepts that I talked
about it's much less battery constrained
power constrained CPU constrained we're
also much more likely to be able to use
the human beings external identity
sources so maybe I want to build an app
where and I authenticate a human with an
identity that they already own so their
Facebook or Twitter that Google ID may
be username and password sign-in which
is much easier to for humans to deal
with and the digital certificates maybe
want to associate those kinds of
identities with the set of permissions
within an IOT application that gives a
human the ability to control a
particular subset of devices okay the
way we implement that is with another
AWS service called Amazon Cognito which
allows you to bring in public ID sources
match those up against cryptographic
credentials that give permissions to
operate with particular services that we
provide and then in future maintain that
relationship so whenever I log in with
Twitter or with my Facebook ID I get the
same identity within AWS that allows me
to operate on a certain set of resource
you could implement something you're set
yourself the same of course we're
talking about open ID Connect we're
running your own identity provider and
then we're talking about issuing
policies to customers or consumers when
they connect to the service or you could
use a platform for it but you need to
make sure that you handle that part of
the equation as well it's not something
that can be can be forgotten about and
isolated okay so that's all about
cryptography and making sure that we're
we're communicating with our things in a
way which is non reputable in a way
which can't be tampered with or
eavesdropped upon strong thing identity
okay
I mentioned certificates already okay so
these are the things the things the
digital assets that are used to identify
the things there's too many things in
this talk you can get confusing so I
said before
x.509 certificates they're no different
to the digital certificates that are
used for HTTP tls/ssl connections okay
you're going to have your cert which
contains details about your entity who
you are you're going to have your public
key embedded within it you're going to
sign that with your private key you're
going to send it off for a certificate
signing request the CSR with a
certificate authority that could be
Verisign it could be your own
certificate authority that you run the
and at that point you can use it if you
used it in a browser you would see that
reassuring little padlock pop up in the
bottom of the browser indicating that
this connection was made using a signed
certificate in our model that
verification process is an implicit
component of allowing a connection to be
established so if you don't have a sign
cert and you don't have a root
certificate associated with that signs
available to you then all bets are off
and you can't connect to our service
endpoint you should build the same thing
if you're building this yourself you
want to use a truss tree when you want
to use a certificate authority to verify
the identity of the devices by digitally
signing these certificates that they use
that can be quite an overhead actually I
mean talking about device prototype
I've got a Raspberry Pi or a Nord we
know or some of the microcontrollers
sitting on my desk I'd get my
certificate so I get them signed that I
flashed them onto the device right I do
that over a USB cable or using an IDE
there's me and my device sitting next to
me of course when you go into
manufacturing things get a lot more
complicated the devices aren't sitting
next to me they're in a semiconductor
integration facility in Taiwan or in
China somewhere the being built by a
party that maybe I don't trust actually
maybe I don't trust the party that is
doing the building okay so the I've got
to give my crypto materials my public
and private key and my digital
certificates to a third party and my
third party has to flash those
cryptographic materials and those
certificates onto my devices as part of
their manufacturing process yes so now I
have fifty thousand five hundred
thousand or five million of those things
that have been built in that factory how
do I go about authorizing them for
access maybe it's not a great idea to
authorize all of them yeah so how do I
do that
the way we solve for that is you can
register your own certificate authority
as I said before to sign these
certificates okay so you could sign your
own certs give all of your certificates
all of your cryptographic materials to
your manufacturing partner your
manufacturing partner receives a data
dump that has all of that data in them
and they sequentially flash those onto
the devices maybe they've record the
serial number of each device when they
do that flashing and they give you back
a corresponding key value file which has
serial numbers and the certificate IDs
with it okay so you know which serial
number of device has which certificate
on it we support a feature called
just-in-time registration of device
certificates this allows you to specify
details of your certificate authority
each time a certificate presents which
has been signed by that named
certificate authority we will create a
policy and
attach it to the new certificate but we
will put the certificate into an
inactive State okay so we know about it
but it's not active it's not permitted
to access our endpoint you can then run
an async process where you validate that
the presented certificate matches a
device a serial number that's been
registered or sold using an external
source and once you've done that you can
then activate that certificate and that
certificate and its private key will
then become usable for connectivity to
the platform okay so you have a multi
stage registration process where whilst
you've put your cryptographic materials
into the hands of a party that you
cannot necessarily trust 100% those
cryptographic materials aren't actually
except don't actually provide access to
the platform you have to go through an
additional verification stage to switch
the access on allowed those certs and
crypto materials to be used for sending
and receiving messages so that's a good
step to go through if you're building
yourself to ensure that only trusted
devices are able to connect we also
support the simpler option which is key
pair generation and certificate
generation for prototyping and for that
you can just use a command line or
clicking option in our console will spit
out the required cryptographic materials
and the certificate and you can get
started in a few seconds okay but for a
lot production manufacturing we wouldn't
recommend that would recommend using
this multistage process so you can
verify that each client is authorized to
connect before you authorize them to do
so by the way that process that I've
described that actually uses another AWS
service called AWS lambda in the
background so the registration process
is actually serving us you just write a
function activates the certificate on
the basis of verification you don't need
to run infrastructure for that we may be
talking about that offline if you're
interested so that's all about the
transport there really it's about
verifying who's connecting to me and
ensuring that I've got appropriate
cryptography in place to protect the
traffic that they're sending to me in
particular traffic that I'm sending back
we haven't actually talked about any
features yet all we talked about is
getting the basic plumbing in place that
allows you to
receive data anywhere which is trusted
and secure right so let's move on and
talk about fine-grained or and to talk
about this this is where I do have to
talk about a bit more AWS specific
specific stuff because the fine-grained
authorization kind of depends on what
your features are what are the services
you need to integrate your devices with
in order to deliver the actual
attributes of your product your
building so what we've talked about so
far is all this okay so the device
gateway that's what your devices connect
to we have an authentication
authorization layer which I just talked
about digital certificates and then out
on the devices we have SDKs just to
accelerate the development process and
they believe to use some of this
functionality at the back you can also
use open source clients like Eclipse
paho which is the most widely used open
source MQTT client because this gateway
supports the MQTT protocol anybody not
familiar with MQTT is that a new acronym
to anybody in this room
okay so MQTT it's developed by IBM in
the early to mid 90s message queue
telemetry transport gives a hint to
which product group IBM developed it
more than anything else it is a protocol
for sending receiving messages so you
can establish connectivity you can send
data through sockets okay in that data
and today is typically blocks of Jason
that you would send it's a pub/sub
protocol that supports a logical
construct called topics and also a topic
hierarchy okay so you can have a topic
name which might be something like
application slash thermostats / 105 or
can subscribe to topics individually or
subscribe to wildcard topics so I could
scribe subscribe to all messages on
application / thermostats I would get
every message associated with any
thermostat that had published a message
on one of those topics and
correspondingly I could subscribe to
applications / chillers and get all the
messages on there or I could subscribe
to specific devices by subscribing to
specific
okay so it supports wild carding in
topic it's a very lightweight protocol
much much more lightweight than HTTP
more terse in terms of its syntax
protocol syntax and it's much more power
efficient particularly when you use it
over this mutual TLS or if you compare
mutual TLS off with MQTT to sending the
same message via HTTP POST over SSL
you're looking at 180 times more power
consumption for option two than you are
flopson one so it's dramatically more
power efficient okay that's why it's
popular we also do support HTTP here and
we also support web sockets as well so
you're not forced to use MQTT but it's a
very lightweight efficient and
cryptographically secure mechanism for
connecting connected devices to a
gateway this doesn't have to be our
thing here with open source tools
there's big project called mosquito
which is an open source MQTT gateway
this would be a power and qtt client the
two things could still communicate you
could still subscribe systems at the
back end two topics on your Mosquito
gateway and you could still build logic
okay the problem the challenge with that
is horizontal scaling which we heard
about in the keynote it can be quite
difficult to do if you have a lot of
messages okay so you're gonna have a lot
of messages throwing through your
gateway once you get beyond the limit
that a single machine can handle at the
back end then you've got a distributed
systems challenge that you need to work
with concurrency message DG application
lots of other issues that you've got a
challenge tackle tackle we do that in in
the platform okay and then these other
things this allows you to inspect the
contents of messages and route them on
the basis of those contents so say I've
got a message off one of my thermostats
which says the temperature is now 61
degrees okay I can have a rule which
says select star from app slash
thermostat slash where temperature is
greater than 60 degrees and then I can
have actions associated with that rule
push it to endpoint and send a push
notification to a mobile phone republish
the message on another topic
switches on one of my chillers okay and
I can have multiple logical operations
on each message that comes through my
gateway so I can build powerful message
flows message routing just by using this
rules engine this does scale completely
elastically so you get away from this
distributed systems challenge with
having to subscribe your own machines to
MQTT topics and deal with concurrency
management failure management scaling
and security in that part of the
architecture so that's a service we have
and then on the device shadows this
provides a virtual representation of
device State which is stored in the
cloud in a document database that means
that I can asynchronously communicate
with my devices so my sheep that I
mentioned earlier a good example here
maybe they're in a valley when they go
in a valley maybe the line-of-sight
radio on the collars doesn't work
anymore but every hour I want to check
the status of my sheep so how do I do
that if I can't reach them well if they
publish their status to one of these
shadows every 15 minutes when they're
connected I can connect to that shadow
if I are in another API and I can read
the state of those devices regardless of
whether or not they're actually on the
network okay so a virtual representation
of the device accessible vironment of
the web services API and then shadow
synchronization is called using methods
that are implemented in this sdk here
and that'll push device state back into
the shadow actually uses MQTT to
transport the device state into the
shadow so it's not another protocol it's
just more messaging on specific reserved
topics ok so again that's something that
can simplify the development process the
reason I'm talking about these is
because we're going to talk about
applying policies to them you could
implement this in a different way if you
wanted to build your own infrastructure
they've got the concepts that I'm going
to describe would still apply but you
need to think about how you control
where these messages are routed to and
also how you secure the process of
pushing messages back down to devices
and our implementation is a good way to
illustrate some thinking about that so
what do we have here you know the
difference between control plane and
data plane so the control plane is how
we establish in
the environment okay and the data plane
is the messaging that flows within the
environment in this context okay so I
can label my different resources this is
the control plane this is our AWS IOT
API if I want to register a new device
authorize a digital certificate that's
associated with the device if I want to
strip a digital certificate and D
register a device I've got an API for
that which is the control plane for the
overall service environment that's
represented there the data plane on the
device side well it's the MQTT gateway
i'm sending and receiving me I'm not
sending okay the device is subscribed to
topics okay so the device reads messages
that are published on those topics it's
always a connection that goes from the
device to the gateway never the other
way okay and I can publish on topics and
therefore messages will be read or the
device can publish on topics and
therefore this and this can read from
those topics
that's how data flows through the
Gateway service access its to other AWS
services which I'll talk about in a
second and then the data plane this is
the back channel so I want to write to
exposed via the device Shadow so I make
my state update the SDK is subscribed to
several MQTT topics and through those
subscriptions the device is able to read
the state change and modify it state to
reflect the desired state which is set
in the shadow okay so I need policy
control here what topics can I read and
write from here who is authorized to
register devices had policies register
and D register certificates here who is
authorized to read and write data from a
shadow and here where is my rules engine
authorized to send data to in other AWS
services all make sense quite a lot of
policy control points there but it means
that you have the ability to exercise
fine-grained control over these
different interfaces so this is about
permissions for thing management so here
we're talking about this ok the control
plane and I have policy language that I
can use now in my case in the AWS case
the policy language is
find using our I am policies okay so we
have an identity and access management
service you could build something
yourself similar if you were
implementing this yourself okay
so we have here you'll see policy
language like action IOT update
certificate and there's an allow
statement and a resource star so a
principal to whom this policy is applied
has the capability to update create and
modify certificates okay and over here
you'll see how we can actually exercise
more fine-grained control here I'm
giving principal the capability to
revoke a single thing by doing an update
certificate on a specific named resource
which is a specific certificate from a
particular source address so you can
scope down the policies to fine-grained
granular control over who can do what on
the data plane on the device side you
can do something similar here I've got
another another policy which I'm
applying actually to every resource in
my namespace and I'm allowing publishing
subscription and received to specific
topics so once again I can scope down
the connectivity and permit specific
devices to communicate only with
specific topics that are required for
their function it'd be like locking down
all of my thermostats and allowing them
only to publish to the thermostat topic
okay or maybe to the one associated with
their specific device serial number I
can really scope in and lock down what's
available to me okay I won't go into a
lot more on this but you just need to
establish those control points in your
particular architecture and make sure
that you're able to tightly scoped for a
principle of least privilege around
those control points so the last thing
to talk about hardware security quite a
few different things here so the attack
surface on the devices themselves needs
to be minimized the greatest extent
possible okay this is why
microcontrollers are quite a good option
because they just don't have a necessary
services and functionality built into
them they run a single process and that
process is your IOT process okay so they
don't have a web server they don't have
anything else that you might not want
running on there if you do insist on
using Linux then SELinux and use of
churu and other features that can scope
down the capabilities of the
operating system of course hardening the
could be the whole topic for this talk
really so just use the minimum device
footprint that you can in terms of
software and really lockdown the device
so that if you do have to expose it to
the internet or to anything that's
untrusted really you can minimize the
attack surface there to the greatest
extent you can that's very very
important then you've got some of the
considerations because untrusted
individuals may have access to your
hardware now I'm selling these devices
it might be reverse engineering by
somebody that wants to steal my software
or hardware designs it might be
something more malignant in that you
know it might be trying to subvert my
overall system by breaching the hardware
and for that there are things like
trusted platform modules that you can
use where you establish a cryptographic
rule in Hardware on the device and that
cryptographic root is used for
decrypting file systems and unpacking
the device so that if the device is
disassembled and it's tried and someone
tries to use it in a location where the
cryptographic root is not available so
maybe reading your flash storage via an
external reader to try and steal your IP
for example or get your keys because
they disconnected from the cryptographic
root when they do that all they get is
white noise on the device so there are
techniques like that you can use also
things like IOT gateway dos I mentioned
earlier they can remove the requirement
for you to talk IP out at this side and
you've got many of the protocols that
you can use like laura1 and others radio
protocols non IP protocols that can be
good on this side very low power often
very low range but it can be a good fit
for things like home gateways device
automation industrial use cases where
you're equipping a factory maybe with
sensors lots that can be done on
gateways this is an example of one of
these cryptographic route devices one of
use this crypto manufactured by somebody
called Amtel this one actually is
designed specifically to work with AWS
IOT so it deals with x.509 certificates
using a hardware route that trusted root
certificate that is stored in hardware
it's quite an interesting device you can
just Google amtel's zero touch secure
provisioning if you're interested in
that they cost less than a dollar and
there's something that you would
integrate into each manufactured device
that you built and that would give you a
very high level of hardware security
and also a secure location to store your
crypto certs and your private keys on
the device which aren't on flash they're
actually embedded in that in the zero
touch provision in case pretty cool okay
so let's take away okay and then well
maybe have a bit of time some questions
securing your IOT applications you're
not spending time solving problems for
customers okay so this is my sort of one
sale slide okay so this is the tick away
if you're building a platform for IOT
then you should focus all of your effort
on building a platform if your intent is
actually to build applications and
services for users then focus your time
on building applications and services
for users and rely on a platform which
already solves these problems okay
there's quite we've talked about quite a
lot of stuff there we're barely
scratching the surface of these topics
in an hour
we could spend up days going into these
stuff in in more detail and teaching you
how to use it so avoid that if you can
if you want to build a wearable if you
want to build a smart home if you want
to build a module for a connected car
choose a platform which already has
security built into it could be hours it
could be another and try to avoid doing
it yourself if you were security prefer
pro and you can build a strong capable
platform like this and just build the
or compete with those but focus on that
and don't try and span both domains
don't try and build a product that
services users in a platform that
probably won't end well because you
can't focus on both of those things to
the extent that you should okay that's
my talk