Julie: Hello everyone and welcome to our webinar
on PKI’s role in securing the Internet of Things. I’m Julie Olenski with the GlobalSign
Marketing team and I want to thank you all for joining us today. I’m happy to introduce
today’s presenter, Lancen LaChance. Lancen is the Vice President of product planning
here at GlobalSign. He’s been heavily involved in rolling our existing our IOT implementations
and making sure our infrastructure supports a unique and complex needs that are arising
with new deployments. He is also the lead IOT Researcher focusing on identifying trends
and guiding GlobalSign’s product road map to support IOT use cases.
Please send any questions you have over to Lancen so we can cover them during the Q&A
portion after the presentation. You can submit your questions to Lancen using the questions
box in your GoToMeeting control panel. We’ll keep track and try to answer them all at the
end of the webinar. You can also follow us on twitter at @globalsign where we’ll be sharing
follow up materials after today’s presentation. Now, over to Lancen,
Lancen: Thank you for the introduction, Julie. Today, we”re going to go over PKI for IOT.
Hopefully, we can give you some food for thought and maybe some new insight into PKI deployments
in an IOT ecosystem. We’ll start by looking at PKI’s role in IOT; basically, a quick recap
of traditionally security concepts. Then we’ll move on to look at some key factors of driving
new considerations and deployment models. As GlobalSign’s already been working some
early IOT deployments, I’ll give you a quick rundown of some of those. We’ll try to cover
some of the general solutions we’ve implemented. To wrap up, we’ll provide some insight into
some points to address and lay down some guidance as to where we see PKI’s role in future deployments.
We’re going to try to cover a lot of perspective in a short time here, so in some areas, we
won’t go as deep as we like, but please do use the question feature to line up any questions
for Q&A. Starting off: what is PKI’s role in security
the Internet of Things? I think all the traditional information security concepts still apply
so we’ll run through those, but overall really, PKI will serve to support building and maintaining
trust in an IOT ecosystem. Aligning with traditional information security principles, the first
role we’re looking for PKI to provide is strong authentication. Authentication in the sense
of authenticating devices to cloud services between users and devices and from thing to
thing. These are all areas where PKI is a strong solution. And as Gartner and other
experts have pointed out, PKI has been used to authenticate machines and servers for decades
so it has really strong proof points as well as being an open standard for interoperability.
Given the types of devices coming online like smart grids, elements of other critical national
infrastructures, health monitors, etc, privacy is a major concern. Encrypting communications
to and from these devices is essential. Applying PKI afford some basic and essential mechanisms
ensuring the privacy of communications using encryption. And as Jonathan and Tyson from
McAfee also point out here, privacy needs to be considered from the outside when implementing
any IOT solutions rather than just a bolt on feature after the fact. Well, there’s no
denying the privacy concerns in an IOT ecosystem. I agree in part with Martin here. I think
it’s tremendously important to consider the integrity of data at the time of consumption.
Some of the transformative value we see when IOT future are prophesized relies on devices
being able to make decisions and act on their own without human intervention. In these scenarios,
both the value and risk are directly tied to the integrity of the data.
Consider the impact of scenarios with heart monitors or insulin pumps relying on spoof
data sources, but what about energy regulating components that need to trust operational
executions sent to them? Thinking of these scenarios definitely highlights the value
that data integrity of PKI can provide. So we’ve been issuing certificates to users,
computers and servers for years and meeting these roles that PKI has just described. But
how do the new things in the IOT change the game? When we look at the IOT on a whole,
one of the distinguishing features is the diversity of devices. As we’ve seen a huge
diversification of mobile devices, we’ll see an even greater trend with IOT devices. Each
would be more tailored to a specific use case with different specifications and capabilities.
If we compare use cases between traditional PKI and IOT PKI, we’ll see a notable divergence.
Traditional PKI implementation tend to have common themes like issuing certificates to
users for portal access or SSL certificates for internal or public facing servers. But
every case in the IOT could be a different nut to crack. Within these scenarios, you’ll
need to consider both the devices connectivity and resources as well as how these map to
the requirements or features you want from a PKI. Many devices in environments will be
constrained like the RAM storage or CPU of the devices could be really limited so this
could prevent you from leveraging traditional PKI features. Instead, you’d be forced to
explore feature subset/alternatives to meet your needs. Next, one of the bigger shifts
when compared to a traditional PKI are the trust models needed to support your ecosystem
in the IOT. For example, between what actors or elements in your environment does trust
need to be established? Is this an open ecosystem where users and
devices might be deciding to join on their own accord and not wholly owned or controlled
by you or is it a closed ecosystem where you control or have authority over all actors
in it? We have an example further in the presentation to cover this in additional detail, but given
those considerations, how will you embed, bootstrap or build trust between entities
in your system? The answers to these questions may drive you to some unique or non standard
PKI deployment scenarios. Now on to one of the most common themes of any IOT discussion
which is the massive size and scope of potential ecosystems; these are absolutely essential
considerations as traditional PKI is operated on orders a magnitude lower than these new
IOT scenarios. And you’re going to need to find a CA infrastructure that can match these
needs. In addition to the raw number of devices you’ll be working with, how do the use case
requirements in your ecosystem impact this CA infrastructure?
Also, based on the type of constraints of the devices, where and how will you be provisioning
them and how does that drive the performance and capacity needs of your chosen security
solutions? Life cycle management of keys and certificates now required a combined analysis
of device capabilities, their supporting cloud services as well as the public key infrastructure.
This analysis will drive your requirements for how you will manage and track certificates
through the life cycle. Also, what is the life span of the target devices you’re working
with? Can they be updated after manufacturing of their initial deployment? And then based
on these questions, you’ll want to consider what the technical interface requirements
are for your end devices. For example, are they going to be consuming PKI services through
an intermediate system or are you looking to have the devices obtain certificates directly
from CA services? Additionally, as many IOT deployments are external customer facing,
are their drivers motivating in alignment of costs and revenue models?
And if you’re going with managed serves, can your provider support flexible pricing models
that match your business case? So those are a few of the new questions IOT has brought
to the table. Let’s look at how some of these considerations are being addressed in the
field of GlobalSign’s existing implementations. Our first example here is with a provider
of cellular signal amplifier devices; SpiderCloud Wireless. SpiderCloud’s node sit within warehouses
or office building to build a system that extends mobile coverage. During manufacturing,
publically trusted certificates are embedded into a trusted platform module or TPMs which
enables a secure boot process, mutual authentication and encrypted communication with the SpiderCloud
appliances. They accomplish this leverage in GlobalSign’s
M/SSL platform and APIs to provision certificates during manufacturing and also during the system
life cycle to reissue and renew the certificates. The next example we have is with Napera. Back
in 2008, they became one of the first companies to use a valid fully vetted X.509 digital certificate
for networking gear which they managed over HTTPS. They chose to use PKI to solve their
problems of identifying the device and encrypting the connection. To implement this, each appliance
has its own unique fully qualified domain name. They use our API to import the certs
on to each device. It was important to them to include the certificate with each appliance
so that the end user organization wouldn’t have to obtain a certificate themselves or
use a self-sign certificate. They also chose to use publically trusted certificates so
that administrators would be shown trust indicators when accessing the devices with browsers rather
than the self-sign certificates which they had used for beta deployments.
The next example is with a national network provider securing network access devices.
They embed SSL certificates into these devices which are located in public locations like
McDonald’s and Barns and Noble. The certificate on the device secures the connection between
the device and the end users as well as between the device and the company’s back end systems.
This is done using our customizable trusted route set up to push certificates onto each
device. To manage the risk associated with the physical security and control of the devices,
they arrived at a solution using short lived certificates and replacing them every 10 days.
This is an interesting example as it contrast some of the other use case as provisioning
and installation is done outside of manufacturing. Those are some examples of early stage IOT
deployments. More of a hybrid between standard PKI deployments and the higher volume varied
device deployments that we expect to see as IOT grows.
In those cases, existing PKI capabilities were mainly sufficient, but as the number
of devices continues to grow and become more varied, it’s likely that PKI as it stands
today won’t be able to cut it. So let’s take a look at some of the considerations that
need to be addressed in order for PKI to take on the scale and diversity that comes along
with the IOT. When comparing the PKI needs of IOT to traditional PKI deployment, there
are a number of top level areas where they start to diverge and we’ll highlight here.
Depending on the capabilities or constraints of the devices in your environment, you may
be looking at leveraging certificate validity periods much longer than traditional certificate
validities. For example, you might want to use this path
if you’re not able to update the devices once they’ve been deployed. Conversely, in some
scenarios, you may not wish to use revocation services. For example, if you have a more
uncertain and dynamic and physical environment you’d look towards using shorter certificate
validities with continuous updates to manage that risk. If you end up going with longer
certificate validities, you may need to consider stronger than standard cryptographic algorithms
and key sizes to meet the future proofing needs. As we mentioned, devices may be resourced
constrained with processing and storage and you look towards more efficient algorithms
like ECC for faster key generation and signing or you may wish to consider shorter root hierarchies
for quicker chain validation. Boot strap and trust in an ecosystem is a really tricky problem
and is going to vary greatly depending on your environment. For example, you may chose
to boot trust by embedding a root with the devices at time of manufacturing.
As the certificates deployed in your environments, likely will be to address new use cases and
functionality, you may find the need to leverage non-standard or custom EKUs to support advance
access control or permission management. Finally, the method of identifying and naming these
devices will likely be non-standard so there’s a high probability that they will need to
use subject names not aligned with the standard naming conventions. In addition to the unique
cryptographic and certificate feature requirements, we need PKI services that can support both
the volume and velocity of usage within an IOT ecosystem. As we mentioned before, PKI
needs to scale and support millions of certificates rather than the thousands of existing deployments.
Additionally, to achieve these high volume scenarios, it’s essential that the PKI services
are exposed via effective, simple, and flexible APIs for complete automation.
And finally, within your ecosystem, you want to understand what the performance and availability
needs are of the relying servers and devices. Before we get into some examples of how this
newly evolved PKI can accommodate IOT, I want to take a step back and discuss who’s driving
these changes. There’s two key stakeholders to address who will be dictating the use cases
and requirements for securing the things in the IOT. First, we have the cloud players
like platform providers or application developers who are relying and generating value from
the data of the Things. And then we have the Thing manufacturers; in some scenarios, these
may represent the same companies. In others, they are separate. Each party might have different
priorities when it comes to security. For example, a platform provider might be most
concerned about the integrity of the data coming into the device.
Whereas the manufacturer might want to ensure that the device only downloads approved software
updates. We’ll next look into two scenarios from the perspective of these players. First,
we’ll look at the platform provider use case. Here we’ll walk through a theoretical cloud
provider model. In this example, the provider has a number of services. They have Thing
web services for the things to consume and collect data through, consumer web portal,
an admin portal, a partner web portal and data web services. In each one of these services,
they have a number of actors engaging with those and consuming them. First, we have the
Things consuming web services, and we have consumers using the consumer web portal to
access the data or analytics for those things. And they may also be interacting with the
Things directly. We have an administrator working for the cloud provider administrating
the services within the portal, and the cloud provider might have a couple types of vendors
that are either working through their partner web portal to view and access data or directly
integrating to their data web services via API. Then there might be third party developers
or applications that are integrating and providing additional applications on top of the cloud
provider model, and they could be integrating directly with the web data services and likely
providing access for the consumer through a third party channel. For each one of these
interactions, you’ll need to consider what the trust model it is will be sufficient.
In this theoretical scenario, we’ll propose some options, but in reality, the exact deployment
is going to be completely driven by this specific business needs. But there are two basic modes:
one with public trust, basically leveraging the public PKI model and then they have a
private trust where this is a more closed section of the ecosystem.
First with the Things connecting to the web services, you’ll often be able to get by with
a private trust model. With the consumer accessing the web portal, you’ll likely be using standard
SSL and therefore try to leverage and bootstrap the public trust. With consumer accessing
the Things directory, it’s definitely a more highly debatable area, but the private trust
model is often sufficient here, but you might be looking at a public trust scenario as well.
With administrators accessing the portal, there’s a potential for a closed section of
the ecosystem there so you might be able to get by with private trust, but again, as we’ve
mentioned before, this is very specific and it could be a public trust requirement there,
too. With the vendors accessing the data web services and partner portal, you’re likely
looking to provide a public trust interface for both of those services as you don’t control
or have as much authority over the vendor ecosystem.
And similarly, with third party applications, you’d be looking towards a public trust model
to secure their access to data web services and also consumer access to the third party
application. Whereas this connection right here might be the responsibility of the third
party application provider rather than you as the cloud provider. Now, let’s look at
the other side of the field with the device manufacturers. In this side of the equation,
there are a number of places in the devices lifecycle where you’d consider integrating
PKI. Where and when in this lifecycle you end up choosing, ultimately depends on the
capabilities of the devices or things in questions. The earliest entry point and on that we’ve
come across a number of times is to embed both authentication credentials as well as
trust anchors via X509 certificates with the device at time of manufacturing or time of
software configuration. The nature and feature of the certificates
used in this case will be driven by your business needs as well as constraints regarding updating
the device during its lifecycle in the field. However, there are still a number of other
times in the lifecycle where you may consider provisioning our enrollment. For example,
you many have a more flexible platform that affords enrollment of PKI credentials at the
time of deployment in the environment. So instead of provisioning the device with actual
certificates during manufacturing, you’ll only provision with configuration details
which allows the device to initiate an enrollment process via the cloud services you’ve set
up once it’s deployed. But once the device is in operation in the environment, your approach
for how you handle key certificates and trust across the device’s lifecycle is again, going
to be dictated by the capabilities of the device.
You may or may not have the ability to refresh or update certificates or keys on the device.
These types of considerations will drive PKI encryptographic choices like longer validity
periods or methods of bootstrapping. As we alluded to before, they may be also some business
drivers here like if you’re selling the device with a service or rather collecting an upfront
fee for both which may constrain or guide your PKI implementation decision. We’ve looked
at how some use cases are driving new technical considerations for PKI, but what about overall
IOT security standards? IOT is definitely in its infancy and at full hike. Many implementations
aren’t focused on security right now, but rather concentrating on the value of their
services and devices. The best practices for security are still developing, but some groups
have formed to tackle the task. There’s a huge number of groups on the problem,
but each with it’s own slightly different perspective and concerns. For example, we’re
seeing some interesting work from groups like the IETF who are looking are at applying and
modifying existing internet standards and protocols in the IOT, but they are also doing
some good work on authorization and access control. I, triple E has a number of vertical
specific standard work groups and One M2M who are working on cross industry protocols
and standards. Across standard groups, there’s a good deal of siloing we see in specific
verticals or industries. For example, we have ZigBee with a strong focus in energy. Ant+
and medical devices and Thread with Google, ARM and Samsung focusing on home automation.
However, many standards and initiatives are really lacking commercial attraction so there
aren’t any clear winners yet. And you’re going to best served to lean towards
options that aren’t locking you into a proprietary solution. So back to the question at hand,
is PKI the answer to securing IOT? We may be biased, but we think it’s probably the
best option out there right now. It involves established standards and covers all the basics
of authentication, encryption, and data integrity. The key take away though, as we’ve tried to
repeat many times here is that each deployment is going to have it’s own needs so you want
to work with an IOTCA provider that’s flexible and can accommodate your business driven environments.
Focus on avoiding closed standards and leveraging best known PKI practices and using existing
technology where possible. Thanks everyone for listening.
Before we get into the Q&A, I want to give everyone a heads up that we’re also planning
some related webinars for early next year. One on managing identities in the IOT and
one on our high volume CA services to accommodate the scalability concerns we discussed earlier
in the presentation, so please stay tuned for when those come out. Thanks again for
checking out our PKI and IOT webinar. Feel free to get in touch with us on our Facebook,
Twitter page or LinkedIn page or visit us at www.globalsign.com