>> Stefan Saroiu: Hello everyone. My name is Stefan Saroiu. I'm a researcher in the mobility
and networking research group. It's my pleasure today to post Chen Chen who is a graduate
student from ETH Zürich. Chen was a in a summer internship with Alec and I last summer and
he is going to tell us about his work over the summer called cTPM. Now the format of the talk
is a little unique. We have two goals in mind. One is to present this work at MSR, but also to
have a little bit of a practice talk for him. He's going to give this talk tomorrow at this
conference in Seattle. If you don't mind, if you can hold your questions until the end. He is
going to talk for about 20 to 25 minutes and afterward we will have ample time to discuss and
ask all your questions and we actually welcome multiple discussions afterwards. That will give
us a little bit of an opportunity to time his talk and have an idea. So Chen is from ETH like I said.
His advisor is Adrian Perrig who has recently moved from CMU to ETH and Chen moved with
him. Go-ahead.
>> Chen Chen: Thank you Stefan. Hello everyone. My name is Chen Chen from ETH Zürich.
Today I am going to present my work cTPM, a cloud TPM for Cross Device Trusted Applications.
This is joint work with Himanshu Raj, Stefan Saroiu and Alec Wolman from Microsoft Research.
To motivate our work, today, people are increasingly using more than one mobile device and
sharing data across these devices has greatly boosted user experiences. There is another trend
in the mobile computing world. Applications have started to use trusted hardware. One
important such trusted hardware is TPM and, for example, the Google Chromebooks use TPM
for different features including firmware go back provision and for encryption. And Windows 8
uses TPM for applications like Plogger and virtual smartcards. There are also many research
prototypes proposed by the research community. Among them are Pasture, which offers offline secure off-line data access, trusted sensors which use TPM to send the sensors readings
and trusted long-range runtime which provides TLR long-range runtime for building trusted
applications. We further notice that cross device data sharing is easy. Today, in fact, most
applications build some form of data sharing or app state sharing across multiple devices to
boost user experiences. However, for these trusted applications which merely stores their app
state data on crypto keys in trusted hardware like TPM sharing this TPM protected data
becomes hard. The primary reason for this difficulty is that the keys managed and protected by
the TPMs are by TPM design bound to that TPM chip. Let me use this animation to show why
this is the case. At the beginning a set of root keys are stored in the TPM chip by the
manufacturers. After that these root keys are guaranteed never to leave the TPM chip. The
keys created by the TPM will either be in the TPM chip or protected by these root keys when
they are outside of the TPM chip. As a result, as long as these root keys never leave TPMs the
key generated by the TPM will be secret only to the TPM chip itself. Current TPM specifications
did provide a mechanism for key migration. However, to use this key migration, which is to
marry the key from one TPM to the other, a PKI from a third-party had to be provisioned. Also,
configuration of this key migration has to run in a malware free environment. Both of these
requirements are actually challenging to mobile devices. I will come back to this point in two
minutes. The main research question in this work is what is the minimal change we can make
to a TPM design to enable cross device data sharing. Our answer to the question is cTPM which
is short for cloud TPM. As indicated by the name, cTPM uses cloud services to provide multiple
features including key migration across TPMs. Compared to the current TPM design, the
primary change we made is to require additional root keys pre-shared with the cloud. Let me
give you a flavor about how we can use these root keys to enable easy data sharing across
TPMs. Let's assume two TPMs are running on two mobile devices that belong to the same user.
The cloud provides two TPM emulators as cloud service for the user, and these two TPM
emulators are bound to the same user. Each of the cTPMs will share root keys with one of the
TPM emulators. With the root keys shared between the cTPM and the TPM emulators, we can
establish a secure communication channel between each pair of cTPMs and TPM emulators.
With this secure communication channel and with the help of the cloud, sharing TPM protected
data becomes easy. What's more, with the established secure channel, the cloud can further
provide additional two features for cTPM. Today, TPM chip usually has a small and slow
provision storage device called NVRAM. Each slot of NVRAM could only be written around
10,000 times during its entire life. With the established secure channel, the first feature that
the cloud can provide to cTPM is a fast and large remote NV storage. As for the second teacher,
current TPM chip only has a trusted timer in the design. It doesn't have a trusted clock. That
means the policy this movie can only be watched after midnight Friday cannot be enabled.
With this established secure channel, now the TPM can build a clock and sync this clock with
the clock in the cloud. Now this helps enable moderately interesting time relevant policies.
Here is an outline of today's talk. After talking about our motivation, let's talk about TPM as the
background in case people are not familiar with it and then I will talk about why design
alternatives are not favorable. TPM is short for trusted platform module. It is a secure
coprocessor offering multiple crypto primitives. It also enables measurement and attestation
of code running in the platform. It is vital for trusted computing technology and is widely
deployed in laptops by the producers such as HP or Dell or et cetera. Notice, trusted computing
group defines specifications for TPM. Current complete specifications is TPM 1.2. It is widely
deployed in the TPM chip available. There is one additional specification to replace TPM 1.2.
That is TPM 2.0. Our cTPM is based on TPM 2.0, but I want to point out that our design does
not rely on any features specific to TPM 2.0. cTPM can be easily applied to TPM 1.2. In this
work we adopt similar threat model to current TPM. That is, all sorts of software attacks,
including malware, will be considered in our threat model. However, we don't consider
hardware attacks, such as micro-scoping the TPM chip and without the root keys. For the trust
assumption, cTPM keeps a dual relationship with the cloud. On one hand, we trust the cloud
with all the shared root keys with the cloud and the keys derived from these root keys.
However, it isolates the root keys that exist in current TPM design and keeps those keys local to
the TPM chip. As a result, if the cloud is compromised, only the key shared with the cloud will
be compromised. The keys that are local to the TPM chip are still secure. Secured cloud side
service without trusting the cloud, has been an active research area. We believe securing the
cloud side of cTPM is our future work. For now, let's assume that the cloud can be trusted not
to leak the shared root keys. As an alternative, secure execution mode could be used to
implement TPM extensibility mechanism. This mode is also called trust execution technology in
Intel. It implements a CPU based reboot and sets up an isolated environment to run trusted
code. It will be generally used to implement additional TPM functionalities such as key
migration across TPMs. In order to remove our new system out of the trust computing base,
we can implement TPM, additional TPM code in two steps. In the first step we suspend the
operating system and issue the secure execution mode. And then when in this mode we can
run this additional TPM code. In the second step after the code is finished, we can do any
necessary cleanup and exit secure execution mode and continue to resume the operating
system. These two steps may seem simple, however, it is quite challenging to use secure
execution mode in this way. First, it poses some performance issues. As the operating system
and all applications have to be suspended in the platform. No progress can be made on the
entire platform until this additional code for TPM is finished. Also, since the operating system
doesn't exist in this secure execution mode, the additional TPM code is like running on bare
metal, therefore this causes some engineering issues for the developer of this additional TPM
code. In fact, the processor doesn't have this secure execution mode, which prevents the
majority of this mobile device to use it from the beginning. As proof of these challenges,
actually, there is no production software used in secure execution mode in this way. After
briefly talking about these alternatives, let's talk about our cTPM design and the
implementations. In this section we will mainly address five design challenges. First, what are
these root keys and how do we provision them? Second, with these root keys how do we
design easy secure key sharing across devices? You will see that this requires a secure
communication channel. And next I will talk about the details of this secure communication
channel. Finally, with this secure communication channel being enabled, I will briefly talk about
how we design cloud side NV storage and trusted clock. First, the additional pre-shared root
keys with the cloud are cTPM root of trust. cTPM generates root keys using a random seed preshared with the cloud. You can imagine that in the future, iPhone and iPad can share a random
seed with the iCloud and the Microsoft surfaces can share a random seed with Microsoft Azure.
With this random seed on each boot up, cTPM can specifically generate two root keys. The first
one is called cloud root key or CRK. It is used to protect all the secrets shared across TPMs and
with the cloud. The second key is called cloud communication key or CCK. It is used to protect
the data exchanged between cTPM and the cloud and to establish this secure communication
channel. Let's talk about our design of secure key sharing across cTPMs. The cloud root key
plays a significant role here. Suppose two cTPMs on two mobile devices belong to the same
user want to share keys. In cTPM this is done in three steps. In the first step, the user asks the
cloud to generate a shared key for his devices. The cloud will use command TPM to create a
shared key among these two TPM emulators. The shared key output by the TPM to create will
be protected by the CRK of each TPM emulator. In the next step the key will be shipped with
this secure communication channel to cTPM. And in the final step, the cTPM device can just
use the command TPM to load the shared key protected by the CRK and then provide a handle
for later use. At a high level the cTPM only executes one simple command and it doesn't
require either secure execution mode or a PKI. The only missing component here is the secure
communication channel in step two. Let's talk about these details about this secure
communication channel. In cTPM they use cloud side NVRAM as the message box for the cTPM
device and the cloud to communicate. In general, sending and receiving messages by cTPM is
like NV write and NV read to the cloud side NVRAM. You can think of this abstraction like the
design in UNIX where the kernel code and the user mode code use the file system interfaces to
communicate with each other. Also, as transient connectivity loss is common on mobile
devices, we further design client-side cache to mask this transient connectivity loss. We
provide synchronization protocols to sync the client-side cache with the cloud side provision
storage device. Here are the details of our synchronization protocols. We design a pull and
push method for NV read and NV write. Each of the synchronization processes include two
messages, switch between cTPM and the cloud. Here I want to highlight two details about our
synchronization protocols. First, the messages are protected by the cloud communication key.
Second, the counter and nonce are used to prevent message replaced by the software stacks on
mobile device and the network node in the middle between the cTPM and the cloud. I further
want to point out that in each of the synchronization protocols, it is the TPM who initiated the
command and initiated the connection with the cloud. However, in current TPM usage model,
TPM is supposed to handle command and return results. It cannot initiate connection with the
cloud, so there is a problem. To solve this problem, we propose a method called secure
asynchronous communication. In this method, the caller app assumes the position of a
connection initiator and message forwarder. Each synchronization process will be divided into
three phases. In the first phase, the caller app will issue a demand to cTPM and obtain a blob
from cTPM. In the second phase the caller app will forward this blob to the cloud and then
obtain a response, blob prime from the cloud. In the third phase, the caller app will forward
this blob prime to cTPM and obtain the result for the command. One innovation of this method
is in phase 1 and phase 3, latency could be very short. cTPM will be blocking. It will not handle
command from all other caller application. However, in phase 2 whose latency is [indiscernible]
from natural latency and this latency could potentially be very long. cTPM can continue to
handle command from other caller apps. This helps to improve the responsiveness and
availability of cTPM for other caller applications. Next, I want to remind you that here only
cTPM and the cloud are trusted. The caller app is not trusted, so here, essentially, we create
secure communication channel based on entities we do not trust. With this secure
communication channel established, let's talk about how we can design cloud side NV storage
and trusted clock. Here is a picture to show how a remote NV RAM slot could be read. During
this process, a synchronization protocol is used to sync the client side cache with the cloud side
provision storage. After that, the client can just use NV read to read the content out of the
local cache. Suppose the caller app would like to read NV index 42 from the cloud. It will first
issue TPM to sync begin which is a new command implemented by cTPM to tell cTPM it wants
to access NV 42. In the second phase the cloud could use TPM to sink Proc, to process the blob
and return a response. In the first phase, third phase the caller app can use TPM to sync and to
allow cTPM to process the response and obtain a return code of this command. If the return
code is success, that means synchronization protocols successfully sync the local TPM cache
with the cloud side provision storage. Now in the final phase, the caller app can issue NV read
to read the content from this local cache. In our remote NV storage design, all the local cache
and the interests will have TTL values. If the TTL expires, the cached NV entry is no longer
available. It has to be re-synced. Also, cTPM has a timeout to abort these pending cloud
commands. The cloud can adjust this timeout value according to its needs. The current default
value is 5 minutes. Finally, with this remote NV storage established, building a trusted clock for
cTPM is relatively straightforward. The cloud can just reserve special NV index for the client
and put the clock information into this special index. Now the client can read the clock
information out of this special NV index and even build policies upon this NV index. The only
difference between this special NV index and other normal NV indexes is it uses a different
timeout to keep high precision. The default value for this timeout is one second. For
implementation details, in total cTPM adds three new commands outside of 108 commands in
current TPM 2.0 specifications. The usage of these commands are covered in previous slides.
Our cTPM is implemented based on TPM 2.0 reference implementation. This involves 1304
lines of code outside of 23,000. Finally, to prove the usefulness of cTPM we reimplement
Pasture and Trinc to work with cTPM. For Pasture we extend the functionality to work across
multiple devices. And for Trinc we provide high-performance NVRAM for it. After talking about
our basic cTPM design and the implementation details, let me share some evaluation results.
Our implementation test bed uses client-side machine equipped with TPM chip to run cTPM
client-side code. We also set up a server running of TPM emulator running in virtual machine
for the cloud service. We use wide-area network emulator to emulate both Wi-Fi and 3G
network with the round-trip time information reported by Huang reported in Mobisys in 2012.
Specifically, in this section we would like to answer three questions. First, are the cTPM
protocols designed here secure? Second, what is the performance of crypto operations of
cTPM? And finally, what is the performance of a remote NVRAM accesses for cTPM? To
answer the first question, we verify correctness of synchronization protocols with the verifier
ProVerif. Here we modeled the attacker with unrestricted access to applications, operating
systems and the networks. And the point of all that verification is the model of our
synchronization protocols. We didn't verify the correctness of our implementation. To answer
the second question, we used an experiment to compare crypto operations between cTPM and
TPM chip. In experiment we created 2048 bit key on both TPM chip and the cTPM cloud side
emulator. We compared the latency of each round of this key creation. In the figures showed
on the bottom the x-axis depicts the number of rounds needed to create this key. And the yaxis shows the latency of each round. This result demonstrated here shows that the latency of
cTPM to create 2048 RSA key is 12 times smaller than that of a TPM chip and the variation is
much smaller. The probable reason for this difference is because the crypto operation and
entropy source our cTPM software emulator are much faster than that of a TPM chip. And the
difference got to be even larger when the cloud used a pastor entropy source and a better
hardware crypto module to build TPM emulators. For the third question, we use an experiment
to compare the performance between remote NV access and the local NV access. We
measured the latency of accessing in the index of 640 events. As the remote NV access usually
require a three-phase synchronization protocol, we actually profile each step of the
synchronization protocol. In the figure shows in the below, the x-axis shows the different
operations on different network connections. And the y-axis shows the latency of each
operation. The different colors show the latency of different steps in remote NV accesses. The
results demonstrate that for remote NV read, this performance is comparable to that of a local
NV read. However, for the remote NV write, it's latency is 3.5 times smaller than that of a local
NV write. Also, the latency of a remote NV accesses is actually dominated by the network
latency. We can expect with better locality access pattern and fast operation optimization.
This performance for remote NV accesses could be better. To summarize, in this work we
presented cTPM which is essentially a TPM chip with additional random seed shared with the
cloud. We demonstrate that with this additional random seed we share with the cloud, we can
enable cross device scenarios, we can easily support cross device scenarios by supporting cross
TPM data sharing. The design change also enables two additional features. They are highperformance NV storage and trusted clock. Finally, we present a full implementation of cTPM
and we also implement Pasture and Trinc and extend their functionalities with cTPM. With
that, I will end this talk. I would like to answer any questions. Thank you.
>> Stefan Saroiu: You are welcome to ask any questions you like, the harder the better.
>>: What kind of applications are you targeting with this? You mentioned things like
[indiscernible] at the beginning of the clock which is a local TPM. What new applications, or
what modifications of existing applications would this enable?
>> Chen Chen: I see. The question is what applications will this enable? For example, like what
additional functionality can be provided for Plogger? A good question. The main applications
considering this work are like research prototypes like Pasture and Trinc. Pasture previously, let
me show you this. The semantics with Pasture with cTPM but let's compare Pasture, the
traditional Pasture and Pasture with cTPM. For traditional unmodified Pasture when it works
on multiple devices, so we have to learn Pasture protocol in lockstep on multiple devices. For
example, Pasture is for, for example, to manage movies off-line. When a user buys a movie
from the cloud provider and they use Pasture to say I want to watch the movie or I don't want
to watch the movie. However, with the traditional Pasture if the user has two devices and
wants to buy a new movie, he has to find all these multiple devices and make decisions about
his previous moves. But with cTPM, Pasture with cTPM, when the user has multiple movies he
can just continue to buy movies or choose to watch or not to watch on one device and all the
decisions can be synced to other devices with the cloud. However, the difficulty here is to do
all of the things in a secure manner. If you look at the Pasture semantics, to achieve this is
actually hard without cTPM. Further, for Trinc, Trinc is used to solve equalization problem for
distribution systems. A key problem for Trinc is it requires a counter NV RAM which can
potentially just be written around 10,000 times during its lifetime. With cTPM enabled, we can
provide this high-performance with the NV RAM for the chip and therefore makes the Trinc
more accessible to mobile devices. For the Plogger since I'm not very clear about its semantics
with TPM, so I cannot reason about it now, but I would like to talk with you more about this
cTPM and Plogger to see how we can build a better Plogger.
>> Stefan Saroiu: I think the other thing would be, another benefit of this for our platform
would be that today if I have multiple apps on multiple phones I have to provision a virtual
smartcard setup on each of them. With this it would be automatically provisioned for me once
[indiscernible] devices because the cloud, or the enterprise if you want to imagine that, could
know what is the right virtual smartcard for me and [indiscernible] and say I want my device
[indiscernible]. And with Plogger another benefit would be although he's right that we haven't
gone very carefully to the details, it would be that you can imagine if devices share the Plogger
encryption credentials, keys, and that might make optimizations interesting where you can
copy, bulk copy data from one hard drive to another, one machine to another and you don't
have to decrypt and encrypt. It would just perfectly accessible.
>>: [indiscernible].
>>: My favorite example would be to have these mobile device password managers, just to
have that so that it's automatically keeping your protected and keeping [indiscernible] for all of
our mobile devices [indiscernible]
>> Stefan Saroiu: We have time for questions, but if that's it, that's fine too.
>>: While you've got that slide up there, when you're [indiscernible] timeouts [indiscernible]
timers, do you have to do [indiscernible]
>> Chen Chen: I see. The question is when we have this timeout, this TTL logic, do we have to
access the local NV RAM to get it to work.
>>: Yeah, particularly, do you have to do a write?
>> Chen Chen: Yeah. So we don't because the TPM chip will have RAM built inside, so all this
logic will be built in the RAM. Think about why we can build it in the RAM instead of NV RAM.
If it is built in NV RAM and the TPM crash, the information stays. However, for these TTL values
it is when the TPM crashes or loses battery, then it doesn't matter if we reset the TTL value
because it's just a lag time for this local cache and the local cache is already gone, so we don't
have to store the TTL value. Also, this helps to make this local NV RAM have a longer lifetime.
>>: Are there any scenarios where if you lost connectivity to the cloud for a long period of time
that you would be worse off using cTPM?
>> Chen Chen: Good question. The question is what if we lost the connection with the cloud,
what functionalities could be harmed by this loss of connectivity. To answer the question, let's
assume another scenario which is Gmail and if we want we use Gmail and we lost our that were
connectivity. We basically cannot send e-mails, right? We probably can still see our e-mails in
our local cache, right? And if you look at, cTPM adds a cloud service and then when the
connectivity is lost it cannot connect with the cloud, for example, clock information or the
content stored in the cloud. However, it can, it can also, it can still read information or write
information to its local cache. As long as its cache is not expired because of the TTL value, it can
be used. However, if this network connectivity is too long, this cache works only with transit
network activity, so the cache will ultimately be expired. Then this cloud service cannot be
used by cTPM.
>>: Another [indiscernible] high-level would be that the cloud made us more ambitious with
our applications so we can provide some new function and we always make sure to add the
function on is secure. For example, when you lose your network connectivity there are cases
when that extra functionality becomes unavailable. It stops working and you could argue, I
think you could argue that in some cases the way it stops working is, in fact, worse than having
a pure TPM that would not offer these extra functions, but would continue to make some sort
of progress in the disconnected phase because you have the [indiscernible] locally. See what I
mean? So it's in some sense the way we are thinking about it is this. Application developers
who should actually understand the usage model and say well, I'm willing to actually take the
risk of stopping the functionality and making the thing worse for the user just because I can
offer this extra functionality. In that case they should use this case. Or they can say, you know
what? I don't need this cloud thing. I don't want to deal with the loss. In which case, you
should fall back on the old TPM because we believe that there.
>> But you could design your apps in such a way that they have fallback paths, so that
whenever the cloud resources are unavailable there is some fallback path and it just uses
[indiscernible].
>> Stefan Saroiu: It's true that, there are, this is when being disconnected from the cloud will
turn off all of the cTPM functionality, all the cloud’s hierarchy won't be able to access it at all.
>>: Because you do want to think hard about what your timeout value should be relative to
your expected network connection characteristics.
>> Stefan Saroiu: Okay everybody. Thank you for coming.
>> Chen Chen: Thanks.