DAN GRIFFIN: Thank you very much, everyone for coming.
This is a nice, big crowd.
So I'm really grateful for this opportunity.
This presentation is on protecting data
with short lived encryption keys and hardware root of trust.
My name is Dan Griffin.
I am the president of JW secure.
We're a Seattle based company that specializes in software development.
Today a white paper is discussing secure time
and mobile computing.
The tool in white paper are linked in blog posts we put
out this morning and my blog is on this slide.
We will talk about the context of this work
of why we need data protection.
What are the foundations for achieving it and how it can
be undermine.
General Alexander, the has of the security agency was
at DEF CON last year to give a recruiting talk.
Did everyone go to that?
Did everyone sign up?
Are there any feds in the room right now?
I actually don't see any hands.
I guess general Alexander's message was a little too controversial
for DEF CON, which is saying something.
Another more open and accepting venues,
the NSA has discussed being more proactive
about secure mobile computing.
Does that strike anybody else as being hypocritical?
All right.
But the big take away for the rest of us is that the NSA is working
on mechanisms for trusting their content
from the Cloud to mobile devices.
They stated as much.
So there must be ways that the rest of us can do the same thing.
Let's review the checkered history of mobile devices.
When laptop computers first appeared, they were awkward and obviously
from the early '80s.
Early PDAs were also awkward, but the trio was kind of cute.
Now half the people sitting at Starbucks has
a laptop and everyone has a Smartphone.
Now that we can work and play in the digital world anywhere
at any time, we actually do.
But as work moves to less computing areas, hackers
and spies are just like everyone else.
They look for the maximum return for the minimum investment.
So their focus is now on mobile devices.
What can be done about this?
The first thing we want to do is define some characteristics
of a trustworthy machine, but if there's one thing we learn
from department terminator 1 and 2 is that machines are sometimes
trustworthy and sometimes not.
Likewise, people talk about identifying the person
in an internet transaction, but it's not a person.
It's a machine and it may or may not be properly expressing
the user's intentions.
Give everyone all of that, how can we be sure that
a remote party is telling the truth?
Desktop PCs and laptops can be configured to be secure.
And users can be trained.
Some of this applies to phone and tablets and some of it doesn't.
It is hard enough to encode password policy when users
have full size keywords.
The keyboard experience is built around auto complete and
is not consistent around aps and devices.
Many mobile platforms still lack the system level extensibility required
by the good third party anti virus systems.
Still mobile devices have lots of untapped functionality that can be
used for increasing security.
So let's see how to use it.
Relatively low root kit risk is perhaps the only aspect
of the phone that is still more secure than the typical PC.
The application level attacks have become much more prevalent.
About a mobile app or game costs 99 cents or less,
you can bet zero attention has been paid to security and that's a chain.
You get what you pay for.
On a mobile, there's risk from geo location to remote theft
of data, remote theft of service.
In short, it remains difficult to get the device do reliably report
on its current state that.
Presents a risk both do back end services and
to sensitive data.
To get reliable information from the device, we need to get
an authenticated report from a tamper resistant root of trust.
This is the purpose of the trusted module or TPM.
It's a crypto processor implemented a tamper resistant chip
on a mother board or as a secure execution environment
in system on a chip firm ware.
The latter is becoming the norm.
Guys intake gritty is the point of the exercise,
but how can that help protect the user and custodian
of the data care about?
First we want to measure that the device is running
the way that it's supposed to be running is the first consideration.
The second consideration is that we want to insure that only
on a compliant device can I decrypt sensitive data and only while
the device remains compliant.
By issuing encrypted content bound to a specific TPM and
to a specific state of that device as reflected in the TPM,
we can really lock down the lifetime of that content.
I'm not going to go into as much detail this time.
There is probably what this means is that determining the half
of the mobile user device requires some infrastructure and it requires
a little cryptographic dance that's achievable.
Nonetheless, I am not suggesting the techniques be applied
to every internet transaction.
They're too heavyweight for that.
But for securing high value data on consumer class devices that are
sometimes disconnected, this is currently
the best foundation we have.
So let's dig in.
With measure boot starting with the bios before each component
in the boot chain is loaded, the previous component computes it's
hash and sticks it in the registers or PCRs.
After boot, a boot log can be retrieved
from the PTM.
The log includes the boot image hashes that I just
talked about.
It also has code signing information as in who signed the binary.
And also includes other boot metadata that is disk encryption.
The TPM can sign that boot log with a special purpose key that you can
down stream if you trust or not.
The server can then issue content decryption or authorization keys bound
to those measurements.
The server encrypts the key to the endorsement key and it
is unique to each TPM.
So when the device state changes, the measurements change and
the TPM will refuse to use that key after.
We have a pretty powerful mechanism here.
Let's see how to wire it together.
Trust starts with a TPM and the key distributed with it.
This key is set by the manufacturer or the OEM along with a PKI certificate
signed by that manufacturer and it's a short list.
If you keep that set of issuing certificates,
you can determine across a variety of things whether you trust that.
The TPM is as protected as any hardware or firmware can be.
Electron microscopes are a problem as is an insecure supply chain.
Importantly, TPM2.0 includes a secure monetizing
increasing counter.
This at least is a more secure option than
the standard PC block is when it comes
to enforcing policies that are time sensitive.
For example, they need to start now and end at a certain time.
They have a limited window that can only be run
once, various combinations of those things.
This counter is the foundation of our work on short lived keys.
Once the client guys has received a measurement bound key
from a remote service, how can we use that key?
Well, consider that constant reauthorization is expensive
and that users hate it, Curborrows has been able
to mitigate some of the burden of reauthorization that way.
The point is that validity period is a policy setting that can be
ratcheted down.
Why not use the same technique to protect mobile data?
So again, for Gory detail of how to implement a data loss prevention
or digital rights solution, using measurement bound keys,
please see the white paper I mentioned
in the beginning of this talk.
To run your TPM through its paces, please check
is out the timed key tool that I mentioned as well.
I warn you that the prerequisite for running that tool are relatively steep
because unless you have a system on a chip based windows 8 tablet ore
laptop from the past couple of months, you probably do not have
a TPM 2.0 system, which is probably a little lame,
but bear with me.
This is a typical concern if you are building solutions on that
like my company is.
We believe it will make sense in the near term.
Especially for small high value deployments.
Also, if you're serious about developing custom TPM middle
ware, you will want to join the trusted computing group
as specifically the TPM sub group.
Because that's how you can download their full TPM simulator
reference implantation.
That will save you months.
But as an additional warning, the ability
to down load that requires a premium membership
because they know the value they are giving you.
So you won't.
Do that as an individual unless you are a dot com.
My blog provides a trace of providing a demo using this tool.
They are verbose to allow you to infer the TPM command sequence.
In summary, you can use the first three commands listed
on the slide to do the following sequence.
You can do other things as well.
There are a variety of commands, but let me run
through what we consider the default case.
First use the tool to create a 2048 bit RSA key and you have
the lifetime of that key to 60 seconds.
Note that another major improvement in TPM2.0 is a limit curve
and symmetric cryptography.
So that raises interesting scenarios using smaller keys, but also
in doing data streaming.
But there's some opportunities there.
Anyway, TPM only supports RSA and TPM does not support
the time bound keys.
This tool is not going to run on a 2.1 device.
The next step then is running the tool to encrypt sample data.
Third, still within that 60 second window,
decrypting data.
Finally, after 60 seconds, do the decryption again and you'll get
the expected failure saying your key is out of policy.
With these capabilities in mind, again, how can we use measurement bound
keys to protect mobile data in the real world?
Consider data access by trusted insiders.
In this casing, we want to insure that only users
with trusted client machines and incremented disks can download
sensitive files first document repository say such as share point or dox.com.
By using platform, hardware identify and we decrease
the chance that the data can be decreased and stolen.
But before you deploy such a system, you should understand what can
go wrong.
Bio integrity or BIM model to protect computers from root kits.
BIM boils down to measure boot, plus TPM testation.
BIM is the model for everything we have just
been discussing.
Based on, this my company implemented
a solution called BHT or bias integrity measurements tool
for fast track last year.
We included this data flow diagram along with that model.
We like it for shock and awe purposes.
We have the user.
To the right, we have a TPM root of trust produced by the manufacturer.
So insecure, more secure.
Note it is only the two rings on the right.
The TPM and the supply chain that were there
with the trustworthiness of the device.
Your remote solution, your middle ware has been
implemented correctly which ask be a big or small assumption depending.
Given that assumption, two other questions arise.
First, you can trust your supply chain and two,
are your adverse easier sufficiently well funded to attack the TPM directly?
We believe that properly engineered middleware can significantly narrow
the window attack on mobile data, but there
is nothing that middle ware can do if your chip set its own.
In order for users to be able to interact within the policy window,
there is necessarily an increased risks of attack
during that time.
In any case, remember that the goal is to prevent the device
from lying about its integrity.
TPM1.2 is widely available on PCs, but to date, not widely used.
The user experience around initialization and provisioning
is quite poor.
And this ask necessitate short cuts about you're trying to deploy
a solution based on these capabilities
in a hetero genius environment.
This problem is solved on the latest hardware.
So hopefully adoption of TPM2.0 will continue to increase.
As I mentioned a couple times, we recommend that measured boot be
used to enforce disk encryption if possibility as part
of data loss prevention.
But in windows, that implies you will be using their bit locker feature.
Bit locker has been the subject of many numbered published attacks.
When properly configured, we think it is good protection.
Note that for other PMM based encryption
solutions such as those you might implement using
this measurement based keys capability, many of the same types
of attacks may apply.
So you need to do your research and do what you can
to prevent exposure and reduce exposure of your keys
in main memory.
This goes back to the streaming opportunity I talked
about before.
That can be a really compelling way to mitigate the exposure of keys
in main memory.
You can decrypt HD content fast enough on a TPM?
I don't know.
When somebody figures out, it will be cool.
Looking forward from my perspective
as a security software integrator, there are three points to consider.
Intel has excellent developer support for technologies we have been
discussing particularly on that atom chip set.
But with the mobile platform strategy for atom be successful,
ARM has been slower to embrace
because no consumer cares.
But if Intel makes TPM a differentiator, will ARM respond?
I hope they would.
Finally, can software companies successfully integrate
the capabilities in a way that is both secure and usable,
with that being the usual trade off?
Anyway, as a demonstrated, short lived keys are a great tool
for mobile data protection.
And 2.0 is increasing.
So learn to trust machines, if only for short periods of time.
Thanks.
[APPLAUSE]
I left tons of time for questions, if anybody has any.
[INAUDIBLE]
DAN GRIFFIN: I mentioned a prerequisite that our current demo
tool depends on TPM 2.0 as well as 32 bit windows.
The point being that's a rare combination these days.
The one test device is the was the ACER iconia W3 which happens
to only be 32 bit.
That is not going to be the norm.
I can guarantee.
[INAUDIBLE]
DAN GRIFFIN: If anybody else has questions, you're invited to use
the mic or I can repeat it.
I'll go to the Q&A room, which is down the hall.
Thanks, guys.