PRACTICAL VERIFICATION OF UNTRUSTED TERMINALS USING

REMOTE ATTESTATION

Simone Lupetti

Department of Computer Science, University of Tromsø, N-9037 Tromsø, Norway

Gianluca Dini

Department of Information Engineering, University of Pisa, I-56122 Pisa, Italy

Keywords:

Untrusted Terminal Problem, Remote Attestation.

Abstract:

We present a technique based on Trusted Computing’s remote attestation to enable the user of a public terminal

to determine whether its conﬁguration can be considered trustworthy or not. In particular, we show how the

user can verify the software status of an untrusted terminal and be securely informed about the outcome of

the veriﬁcation. We present two ﬂavors of this technique. In the ﬁrst, the user makes use of a personal digital

device with limited computing capabilities and a remote trusted server that performs the actual veriﬁcation. In

the second, the personal device is assumed to have enough computing power (as in the case of smart-phones

and PDAs) to autonomously perform the veriﬁcation procedure.

1 INTRODUCTION

One of the fundamental prerequisite to use a comput-

ing device is to trust it to correctly perform the re-

quested operations. The owner (or a regular user) of a

computer is usually (even if not always rightfully con-

ﬁdent about the status of the software of his machine.

The prolonged use of a personal computer, possibly

including the installation and maintenance of the soft-

ware, represent a natural way to build a trust relation

with it.

But while establishing a trust relation by these

means is possible in the case of personal and private

computers, there are settings, such as for public ter-

minals in airports, hotel lounges and Internet caf

es,

where such prolonged relation with a speciﬁc com-

puting device is hard (if not impossible) to achieve. In

these settings it is hard to know the practices used to

maintain the terminal, as well to determine with cer-

tainty the set of programs that runs on the platform.

Notice that these public terminals not only share all

security problems typical of a personal machine but,

because they are potentially used by an large num-

ber of users, the threats deriving from user’s mali-

cious behavior may be exacerbated. The usual way to

avoid unintended interactions among different users is

to map them into different roles on the machine, but

this practice is not a viable option where the user base

is not known a priori.

Therefore, when faced with the need to use a pub-

lic terminal, a user is usually forced to choose be-

tween stepping back and potentially endangering his

security and privacy. As consequence, most of users

will refrain to perform any “critical” operation i.e. any

operation that involves sensitive data such as pass-

words, PINs and cryptographic keys

. This means

that public terminals may be, for all practical pur-

poses, unﬁt to do anything from accessing a web-mail

service to perform an Internet banking transaction.

This dramatically restricts the usefulness of such ter-

minals.

The problem we have described is known as

the untrusted terminal problem and an handful of

very different solutions have been proposed along

the years. Some of them are based on personal

trusted devices, from smart cards (Abadi et al., 1991;

Berta et al., 2005) to camera phones (Clarke et al.,

2002; McCune et al., 2005), others require users

to make “easy” cryptographic computations (Stabell-

Notice also that, while the notiﬁcation that a password

will be sent on an “untrusted” network is a common fea-

ture of most of Internet browsers, the notiﬁcation that such

a password will be typed of an “untrusted” terminal is un-

conceivable.

402

Lupetti S. and Dini G. (2007).

PRACTICAL VERIFICATION OF UNTRUSTED TERMINALS USING REMOTE ATTESTATION.

In Proceedings of the Second International Conference on Security and Cryptography, pages 402-407

DOI: 10.5220/0002123304020407

 SciTePress

Kulø et al., 1999), ﬁnally, other are based on AI trans-

formations (King and dos Santos, 2005).

Differently from the previous works on this topic,

we do not focus on authenticating a single message

or operation but on determining whether the whole

terminal meets the security requirements of the user.

This includes the authenticity of the messages leaving

the terminal but also addresses further security and

privacy guarantees as, for example, that user’s data,

such as typed passwords and browsing history, is not

stored in local memory for later unauthorized use by

other parties. To this end we propose the use of re-

mote attestation, a key feature of Trusted Computing

(TC), to give the user conﬁdence on the trustworthi-

ness of the terminal he is using. This technique is

designed to allow a local platform to authenticate the

hardware conﬁguration and the software stack run-

ning on a remote platform to tune its amount of trust

in this latter (Bottoni et al., 2006).

We present two variations of the our veriﬁcation

technique. In the ﬁrst the user is helped by a trusted

digital deice that is not powerful enough to perform

remote attestation. In this case we assume the avail-

ability of a trusted remote server performing the re-

mote attestation on behalf of the user and securely

communicating him the outcome. We assume the

server is well-known, providing this service as part

of its business, for example. The second scenario we

consider is one in which the trusted personal digital

device is capable of carrying on a remote attestation

procedure by itself.

The rest of the paper is organized as follows. In

Section 2 we introduce the system model. In Sec-

tion 3 we give an overview of Trusted Computing and

remote attestation. In Section 4 we present the two

variations of the veriﬁcation protocol and argue their

resistance to the terminal duplication attack. The pro-

tocol is then discussed in Section 5 together with the

possible vulnerabilities inherently deriving from the

Trusted Computing model. We draw our conclusions

in Section 6.

2 MODEL

A user U wants to gain conﬁdence about the trustwor-

thiness of an untrusted public terminal T . This means

that an attacker can control the complete software sta-

tus of T . However we exclude threats in which the

attacker have physical access to T and is able tamper

with its hardware. With this ability a malicious party

can always gain complete control of a machine and,

under this assumption, no veriﬁcation process would

be able to detect tampering.

Veriﬁer

Untrusted

Network

Scenario 1

Scenario 2

Figure 1: Representation of the two scenarios for the veriﬁ-

cation of an public terminal.

T ’s hardware must be conform to the Trusted

Computing speciﬁcations and therefore supports the

remote attestation procedure as described in (Pearson,

2002). If this is not the case, our veriﬁcation proce-

dure will fail and the user U will not be able to con-

sider T as trustworthy regardless its actual software

status.

We assume a public terminal that supports our

veriﬁcation mechanism to clearly show a label (for

example taped on its screen frame) stating a human

readable ID (more on this in Section 4.3). Notice,

that because we offer security under the assumption

of software-only attacks, the assumption of ID la-

bels as a secure source of information for the user is

sound (McCune et al., 2005).

To perform the veriﬁcation of T ’s software status

we assume that the user carries with her a trusted per-

sonal device P. Initially we will consider this device

to have a simple screen and minimal computing ca-

pabilities. This could be a smartcard with a alphanu-

meric display that can be connected to the terminal

T in order to exchange data with it. We assume that

while P is not powerful enough to perform the whole

veriﬁcation procedure, it is able to compute some sim-

ple cryptographic functions such as message authen-

tication code and to display the user a string of char-

acters. In this scenario we assume the presence of

a remote trusted server S connected to the terminal

T (Figure 1, Scenario 1). The communication chan-

nel between T and S is considered also untrusted. In

particular we assume that an attacker is able to read,

modify, delete and create new messages to and from

T .

Later we will relax the constrains on the personal

digital device considering a more powerful one, such

a smart-phone or a PDA, that is able to carry on the

veriﬁcation process autonomously. In this scenario

the trusted server S is not needed anymore (Figure 1,

Scenario 2).

PRACTICAL VERIFICATION OF UNTRUSTED TERMINALS USING REMOTE ATTESTATION

403

3 TRUSTED COMPUTING AND

REMOTE ATTESTATION

A Trusted Computing Platform (TPM) is a comput-

ing platform entailing a specialized co-processor for

security operations, such as to perform digital signa-

tures and data hashing or to provide protected storage.

We consider the Trusted Computing Group platform’s

speciﬁcations as reference model (Pearson, 2002).

This provides guidelines for developers to enable the

design of security-related functionalities on a TPM-

based system.

Remote attestation is a process with which a host

can authenticate the software stack present in a re-

mote platform. Intuitively, a trusted component called

Core Root of Trust Management (CRTM) starts the

boot process on the remote platform measuring the

BIOS. Then the BIOS measures the boot loader, that,

in turn, measures the operative system’s kernel and

so on, up to user’s applications. A measure is usually

performed by taking a SHA-1 hash of the image of the

software that is being measured. This hash is stored

in a TPM’s protected set of registers called Platform

Conﬁguration Registers (PCRs). A software measure-

ments describe therefore the whole platform’s conﬁg-

uration (Sailer et al., 2004). In this way it is possible

to detect the run of malicious (or simply undesired)

software.

To prevent tampering, access to the PCRs is

hardware-restricted and their value can be modiﬁed

only in two ways: the ﬁrst is cold-initializing the

whole platform (TPM Startup()), operation that set

all PCRs to all zeroes but requires physical access to

the platform (in case the initialization follows instead

from a sleep-mode, the state of all PCRs is restored

to the ones previous the sleep). The second way to

modify the value of a PCR is to use the TPM extend()

function. This latter takes a 160 bit string and tar-

get PCR as input values. The selected register is then

updated as follows: the input string is concatenated

with the current value of the register, then the result is

hashed in 160 bit digest to ﬁt the register length and

there stored. The value for the i-th update of a PCR

(indicated as PCR[i]) is therefore calculated as:

PCR[i] = SHA-1(input string | PCR[i-1])

The value of a PCR can be reported either by a

TPM PcrRead() that produces a non-cryptographic

description of the content of a set of PCRs or by the

TPM

Quote() function. This latter requests the TPM

to produce a signed message that contains the value of

a set of PCRs and some externally supplied data, (typ-

ically a nonce to conﬁrm the freshness of the signed

message)

. The resulting data structure can be used

to implement remote attestation because it assures the

integrity and authenticity of the content the PCR to

remote parties.

To produce this data structure,a TPM has exclu-

sive access to an attestation identity key pair (AIK

−1

;

AIK) securely created and kept inside the TPM for its

whole lifetime. Its private part AIK

−1

is protected in a

way that it can be used only by the TPM itself while a

certiﬁcate issued by an external certiﬁcation authority

binds its public part to the identity of a speciﬁc TPM.

4 VERIFICATION PROTOCOL

We describe here how the veriﬁcation of T ’s status is

carried out by the user ﬁrst with the help of a trusted

personal device with limited computing capabilities P

and the remote server S, and how the user is securely

informed about the outcome. Then we will show how

the same veriﬁcation procedure can be greatly simpli-

ﬁed by relaxing the constraints on the personal device

In both scenarios with T

we indicate the identi-

ﬁer of the untrusted terminal T . We assume this iden-

tiﬁer to be derivable, in some way, from the public

identity key AIK of T by a compression mechanism

such an hash function. For example, if SHA-1 is used

we have:

= SHA-1{AIK}

While details about this are still scarce, we expect

a TPM identity key pair certiﬁcate to contain (at least)

serial number and a series of attributes uniquely iden-

tifying the TPM (the distinguished name, in X.509

jargon). This means that the serial number (or any

other unique attribute) can be used as T

as well. Re-

gardless of what is used as T

, a human readable ver-

sion of this must clearly visible on the public terminal.

4.1 Veriﬁcation by a Remote Trusted

Server

In this ﬁrst scenario we assume the user to be helped

in the veriﬁcation process by a trusted personal de-

vice with limited computing capabilities and a mini-

mal display and by a remote trusted server S that per-

forms the veriﬁcation on user’s behalf. In particular

we assume P to be able to perform message authen-

tication encoding and decoding. In this scenario P

The caller must have the necessary credentials to use

the signing key to generate this message

SECRYPT 2007 - International Conference on Security and Cryptography

404

shares a secret string of characters K with S. A high

level description of the procedure is given below.

Step 1: After user’s request, P produces the follow-

ing one-time login token:

OT P = MAC

(Time)

by computing a symmetric message authentica-

tion code such as HMAC under the key K. The ac-

tual data to be authenticated is a timestamp Time

indicating when the login attempt is being per-

formed.

Step 2: P −→ S : OT P, Time

P forwards the one-time password and the times-

tamp to the trusted server S (using the connec-

tivity offered by T ) to initiate the veriﬁcation of

the local terminal. The use of the one-time pass-

word OT P is necessary because otherwise the un-

trusted terminal could record and reply a login to-

ken to the server S to asking a remote attestation

and therefore potentially exposing S to a DoS at-

tack. OTP serves also as a guarantee for user’s

anonymity because it creates unlinkability of dif-

ferent login attempts from the same (or different)

terminal.

Step 3: S −→ T : “Attest”, N

The trusted server checks that Time is properly

authenticated. Notice that timestamps are here

used only to prevent replay attacks and there is

therefore no needs for ﬁnely synchronized clocks.

The only veriﬁcation done on the value of Time

is that this latter must indicate a subsequent in-

stant in respect with the last login attempt from

the same user. If so, the trusted server S initiates

the remote attestation protocol by challenging the

untrusted terminal. The challenge should include

a nonce N to prevent the host under veriﬁcation to

re-use an old response.

Step 4: T −→ S : {PCRset, N}

AIK

−1

At this point the terminal can respond to the attes-

tation challenge, issuing a TPM Quote() to pro-

duce an answer message containing a set of PCRs

describing the platform status and the nonce from

the attestation challenge to prove the freshness of

the reply. This message is then sent back to S. No-

tice that in some implementations the sole list of

PCRs may not be enough for S to derive the T ’s

conﬁguration, maybe because the value of PCRset

for too many acceptable conﬁgurations should be

known by S. In this case, to allow direct inspec-

tion by S of the T software status, the log of all

executable activations should be sent along with

PCRset. This latter would be also sent to S as it

serves as integrity measure of the log.

Step 5: By the analysis of PCRset (or PC Rset and the

activation log, if necessary) S determines whether

T is in a trustworthy conﬁguration or not. The set

of acceptable conﬁgurations may vary both in re-

spect of the service that the user want to access

(different services may require different conﬁg-

urations) and of the users themselves (different

users may have different requirements about T).

Step 6: S −→ P : Outc, T

, HMAC

(Outc|T

)

S sends the terminal the attestation outcome Outc.

We indicate here that both a positive or a nega-

tive outcome is sent back to T but, in the case the

attestation fails, to send a negative outcome to T

may be completely irrelevant since T , not being in

a trusted conﬁguration could drop this message.

This means that Outc can simply be a conﬁrma-

tion bit in case of positive attestation and nothing

otherwise. What is important, however, is that T

will not be able to produce a phony positive out-

come because it does know K. S sends this mes-

sage to T that forward it ad verbatim to P. We

omitted this additional step for brevity.

Step 7: P −→ U : T

The trusted digital device D veriﬁes the integrity

of Outc and T

, then checks if the veriﬁcation

outcome Outc is positive. If this is the case, it

displays to its screen the terminal identiﬁer T

the same format as printed on T ’s label.

Step 8: The user compares T

that he sees on the

terminal with the one displayed on his personal

device. If they are equal then the user assume that

the machine that S has veriﬁed is really T . Else

S has been tricked into verifying another machine

on T ’s behalf and the terminal is considered not

trustworthy.

4.2 Veriﬁcation by the Trusted Personal

Device

In this second scenario we relax the constraints on the

trusted personal device that is now assumed to able

to perform the remote attestation autonomously. The

veriﬁcation process can this way avoid to resort on a

remote trusted server resulting in a greatly simpliﬁed

procedure.

Step 1: P −→ T : “Attest”, N

The trusted personal device directly initiates the

remote attestation protocol by challenging the un-

trusted terminal. As in the previous scenario the

challenge includes a nonce N to prevent the host

under veriﬁcation to re-use an old response. No-

tice that, since this message does not bring any

PRACTICAL VERIFICATION OF UNTRUSTED TERMINALS USING REMOTE ATTESTATION

405

user identiﬁcation, the privacy of the user is pre-

served also in this version of the protocol.

Step 2: T −→ P : C

AIK

, {PCRset, N}

AIK

−1

The terminal responds to the attestation challenge.

It ﬁrst issue a TPM Quote() to produce an string

containing a set of PCRs describing the platform

status. Then attaches to this string the nonce from

the attestation challenge to prove the freshness of

the reply and send it back to P. A digital certiﬁ-

cate C

AIK

vouching for the authenticity of the key

AIK is also send along with this message.

Step 3: P veriﬁes the digital signatures of

{PCRset, N}

AIK

−1

using C

AIK

. Then P ana-

lyzes the PCRset to determine whether T is

in a trustworthy conﬁguration or not. P takes

this decision exactly as S does in the previous

scenario.

Step 4: P −→ U : T

If P ﬁnds that the terminal T is in a trusted conﬁg-

uration it retrieves or calculates T

and displays

it on its screen.

Step 5: The user compares T

that he sees on the

terminal with the one displayed on his personal

device exactly as in the previous scenario.

4.3 Terminal Duplication Attack

The previous protocol (in both variants) makes use,

among other things, of physical labels containing a

cryptographic digest of the terminal’s public attesta-

tion key AIK. In its last step the user is required to

compare the value on this label with the value, that is

displayed on his personal device P. This is necessary

to establish a link between the terminal that the user is

using and the machine that has been actually attested.

Without this provision the protocol would be vulnera-

ble to a terminal duplication attack where a malicious

host M in an acceptable conﬁguration is measured in

place of the terminal T and the outcome of the attes-

tation is replayed to the user as it would come from T .

At this point the user would believe that the machine

that has been attested is T while, in fact, is not.

Notice that the fact that the malicious host M

is in a trusted conﬁguration (otherwise the remote

attestation would fail) does not help to conﬁne the

veriﬁcation outcome (Outc in the ﬁrst scenario and

{PCRset, N}

AIK

−1

for the second) to M.

While the host that performs the remote attesta-

tion (S or T ) can make sure (by direct veriﬁcation)

that M’s conﬁguration is such that it does not allow

the message containing the veriﬁcation outcome to be

We assume that P is able to verify and use C

AIK

transfered on another machine, the mere fact that it

needs to outputted somehow to the user (in our case

by sending it to his personal device P) requires this

message to escape the (trusted) domain of the ma-

chine that has just been veriﬁed (for example by an

USB or infrared port, etc.). This makes the attacker

able to capture the outcome as soon as it exits M and

reply it at will to any other machine.

5 DISCUSSION

Our technique allows the user to establish the trust-

worthiness of the whole platform she is willing to use.

This means that, once the veriﬁcation protocol has

successfully run on a public terminal, the user does

not need anymore to be concerned about possible ma-

licious behavior of this latter. While most of other

works in this ﬁeld deal on how authenticate a single

message coming from an untrusted terminal, we fo-

cus instead in how determine once-for-all if the ter-

minal can be safely used by the user (at least within

the same session). We believe this to represent a clear

advantage over the other available methods in terms

of usability. The downside of using remote attestation

is that hardware compromization would render tour

method ineffective, while the approaches aiming to

authenticate each single message are immune to such

a threat.

While the trustworthiness of the public terminal T

is established by measuring its software state using

Trusted Computing’s remote attestation, some con-

cerns have been expressed about TC from the tech-

nical point of view.

While this remote attestation gives strong assur-

ance on what runs on a platform, it is still unable

to cope with trojans exploiting the inevitable vulner-

abilities present even in trusted software (Oppliger

and Rytz, 2005). Also, the requirement that all code

containing a runtime that could potentially run in an

general purpose platform (including interpreters, vir-

tual machines, etc.) must be instrumented to allow

measurements of the code it runs, may be hard to

meet. Vendors of closed source, proprietary appli-

cations may not be motivated to provide an instru-

mented version of their software (Reid and Caelli,

2005). However, both these concerns are less press-

ing in the case of a kiosk-like public terminals be-

cause these latter usually run a minimal version of the

operative system and limited number of applications

(typically a just web browser). This would reduce on

one hand the overall size of the software running on

the machine, hence leading to expect less vulnerabil-

ities and, on the other hand these particular settings

SECRYPT 2007 - International Conference on Security and Cryptography

406

may motivate vendors to provide ad-hoc version of

their software (e.i. web browsers, virtual machines

etc.) instrumented for remote attestation to enter the

market of public terminals.

To date it remains unclear, however, how the link

between a certiﬁed platform conﬁgurations and it

trustworthiness should or could be established. While

a given set of PCR’s values (or a log whose integrity is

guaranteed by the PCRs) must be certiﬁed to be used

in remote attestation, it is still uncertain on who will

provide such a certiﬁcation and which criteria will be

used for this purpose.

Other concerns have been expressed about the

ethical and social implication of the complete veri-

ﬁcation of the software state of machine typical of

TC (Anderson, 2003). However we believe these

to be here less relevant because what is measured

is a public terminal, not a general purpose, private

machine where remote attestation may expose user

habits and private data. We argue therefore that the

measurement of a public terminal does not threat the

user’s privacy just because of its public availability.

6 CONCLUSIONS

We have presented a mechanism to allow the user of a

public terminal to gain conﬁdence about its software

state using Remote Attestation a technique provided

under the umbrella of Trusted Computing. Our tech-

nique comes in two ﬂavors: in the ﬁrst one, the limita-

tions due to a minimal personal device are overcame

by using a trusted remote server that performs the ter-

minal veriﬁcation on behalf of the user. In the second,

we relax the assumptions on the personal digital de-

vice and assume that it can autonomously verify the

public terminal without the help of a trusted remote

server.

By the use of identiﬁcation tags posted on the pub-

lic terminal and the trusted personal device, the user

is presented a reliable conﬁrmation that the attesta-

tion process has been successfully carried out for the

machine she is actually using.

Our solution also takes into account user privacy

by enabling her to use a different identiﬁcation token

to initiate each veriﬁcation process. This makes hard

for a set of colluding terminals to link the login at-

tempts of the same user to the veriﬁcation service.

We believe that our mechanism may effectively

enable the use of public terminals also for handling

sensible user data without threatening the privacy of

user’s data.

REFERENCES

Abadi, M., Burrows, M., Kaufman, C., and Lampson, B. W.

(1991). Authentication and delegation with smart-

cards. In TACS ’91: Proceedings of the International

Conference on Theoretical Aspects of Computer Soft-

ware, pages 326–345, London, UK. Springer-Verlag.

Anderson, R. (2003). Cryptography and competition pol-

icy: issues with ’trusted computing’. In PODC ’03:

Proceedings of the twenty-second annual symposium

on Principles of distributed computing, pages 3–10,

New York, NY, USA. ACM Press.

Berta, I. Z., Butty

an, L., and Vajda, I. (2005). A framework

for the revocation of unintended digital signatures ini-

tiated by malicious terminals. IEEE Trans. Depend-

able Secur. Comput., 2(3):268–272.

Bottoni, A., Dini, G., and Kranakis, E. (2006). Creden-

tials and beliefs in remote trusted platforms attesta-

tion. In WOWMOM ’06: Proceedings of the 2006 In-

ternational Symposium on on World of Wireless, Mo-

bile and Multimedia Networks, pages 662–667, Wash-

ington, DC, USA. IEEE Computer Society.

Clarke, D. E., Gassend, B., Kotwal, T., Burnside, M., van

Dijk, M., Devadas, S., and Rivest, R. L. (2002). The

untrusted computer problem and camera-based au-

thentication. In Pervasive ’02: Proceedings of the

First International Conference on Pervasive Comput-

ing, pages 114–124, London, UK. Springer-Verlag.

King, J. and dos Santos, A. (2005). A user-friendly ap-

proach to human authentication of messages. In FC

2005: Proccesings of the 9th International Confer-

ence on Financial Cryptography and Data Security,

volume LNCS 3570/2005, pages 225–239. Springer

Berlin / Heidelberg.

McCune, J. M., Perrig, A., and Reiter, M. K. (2005).

Seeing-is-believing: Using camera phones for human-

veriﬁable authentication. In SP ’05: Proceedings of

the 2005 IEEE Symposium on Security and Privacy,

pages 110–124, Washington, DC, USA. IEEE Com-

puter Society.

Oppliger, R. and Rytz, R. (2005). Does trusted computing

remedy computer security problems? IEEE Security

and Privacy, 3(2):16–19.

Pearson, S. (2002). Trusted Computing Platforms: TCPA

Technology in Context. Prentice Hall PTR, Upper Sad-

dle River, NJ, USA.

Reid, J. F. and Caelli, W. J. (2005). DRM, trusted comput-

ing and operating system architecture. In ACSW Fron-

tiers ’05: Proceedings of the 2005 Australasian work-

shop on Grid computing and e-research, pages 127–

136, Darlinghurst, Australia, Australia. Australian

Computer Society, Inc.

Sailer, R., Zhang, X., Jaeger, T., and Doorn, L. V. (2004).

Design and implementation of a TCG-based integrity

measurement architecture. In Proceedings of the 13th

USENIX Security Symposium, pages 223–238.

Stabell-Kulø, T., Arild, R., and Myrvang, P. H. (1999). Pro-

viding authentication to messages signed with a smart

card in hostile environments. In Proceedings of the 1st

USENIX Workshop on Smartcard Technology.

PRACTICAL VERIFICATION OF UNTRUSTED TERMINALS USING REMOTE ATTESTATION

407