Uni-directional Trusted Path: Transaction Confirmation on Just One Device

System Security Lab

Uni-directional Trusted Path:
Transaction Confirmation
on Just One Device
Atanas Filyanov1, Jonathan M. McCune2,
Ahmad-Reza Sadeghi3, Marcel Winandy1
1 Ruhr-University Bochum, Germany
2 Carnegie Mellon University, USA
3 Technical University Darmstadt, Germany

DSN 2011 - 41st Annual IEEE/IFIP International Conference on Dependable Systems and Networks
Hong Kong, China, 27-30 June 2011
Dienstag, 28. Juni 2011

System Security Lab

Motivation
• Malware can have strong power on commodity systems
• Keyloggers, transaction generators, ... (commit online fraud)

• Credit card companies, banks absorb most liabilities
• Users have disincentive to solve the problem

• Even e-commerce servers are under attack!
• Sony: attackers have eventually stolen credit card data from
several customers
• Recently similar attacks at other game companies

Marcel Winandy Uni-directional Trusted Path:Transaction Conﬁrmation on Just One Device (DSN 2011) 2

System Security Lab

Motivation
• Malware can have strong power on commodity systems
• Keyloggers, transaction generators, ... (commit online fraud)

• Credit card companies, banks absorb most liabilities
• Users have disincentive to solve the problem

• Even e-commerce servers are under attack!
• Sony: attackers have eventually stolen credit card data from
several customers
• Recently similar attacks at other game companies
If all had used our proposed solution,
there would have been no problem! :-)


System Security Lab

Threat Scenario

issue transaction request transaction
request confirmation request confirmation
confirmation confirmation

User Client System Server

• Typical scenarios: online purchases, online banking,
e-government, enrollment for online services, etc.


System Security Lab

Threat Scenario
Adversary



• Adversary: controls network traffic and controls client system
• only software attacks (no hardware tampering)


System Security Lab

Threat Scenario
Server cannot distinguish Adversary
between transactions issued/
conﬁrmed by user or malware

?


• Adversary: controls network traffic and controls client system
• only software attacks (no hardware tampering)


System Security Lab

Our Goals
• Assurance to a remote server that a user indeed
confirmed a proposed action

• Technical solution without additional devices,
but compatible to existing operating systems

• Minimal/no deviation from normal user experience

• Assumption:
Client System hardware provides some form of
secure execution environment


System Security Lab

Our Goals
• Assurance to a remote server that a user indeed
confirmed a proposed action

• Technical solution without additional devices,
but compatible to existing operating systems

• Minimal/no deviation from normal user experience

• Assumption:
Client System hardware provides some form of
secure execution environment
Available on commodity platforms:
PC: Intel TXT, AMD SVM
Mobile: ARM TrustZone; Playstation3: Cell BE

Idea of the Uni-directional
Trusted Path


System Security Lab

Full Trusted Path
Properties:
Application 1. Isolation of I/O channels
2 3 (integrity & confidentiality)
1
Application
2. Assurance for user about
User authenticity of application
Application
3. Assurance for application
OS about user-generated input
Client System


System Security Lab

Trusted Path: Existing Approaches

• Secure GUI (reserved screen area)

• Requires a secure OS

• Secure Attention Sequence (e.g., Ctrl+Alt+Delete)

• Requires OS kernel to remain uncompromised

• Additional hardware indicators (e.g., color LED)



System Security Lab

Trusted Path: Existing Approaches

• Secure GUI (reserved screen area)

• Requires a secure OS

• Secure Attention Sequence (e.g., Ctrl+Alt+Delete)


• Additional hardware indicators (e.g., color LED)


No widespread adoption, or lack of interest from users
(also: usability unclear)


System Security Lab

Uni-directional Trusted Path (UTP)
CPU Properties:
(integrity & confidentiality)
OS
3 2. Assurance for user about
Untrusted Execution Mode
authenticity of application
1 UTP Agent 3. Assurance for application
User Secure Execution Mode about user-generated input
Server
Client System


System Security Lab

Uni-directional Trusted Path (UTP)
CPU Properties:
(integrity & confidentiality)
OS
3 2. Assurance for user about
Untrusted Execution Mode
authenticity of application
1 UTP Agent 3. Assurance for application
User Secure Execution Mode about user-generated input
Server
Client System

• Enable remote server to gain assurance about human-initiated action
• Based on CPU‘s capability to switch between untrusted and secure execution mode
• UTP is only available in Secure Execution Mode:
• Isolated execution environment and control of user I/O devices

• Ability to provide evidence to remote system what has executed in this mode


with UTP


System Security Lab

Transaction Initiation
CPU

Browser

OS
Untrusted Execution Mode Server
User
I/O Devices UTP Agent
Secure Execution Mode

Client System


System Security Lab

CPU

Browser
1. issues
transaction OS
User

Client System


System Security Lab

CPU
2. requests transaction

Browser
1. issues
transaction OS
User

Client System


System Security Lab

CPU

Browser 3. requests confirmation
1. issues (conf. message)
transaction OS
User

Client System


System Security Lab

CPU

(conf. message)
OS
User
I/O Devices

Client System


System Security Lab

CPU

(conf. message)
OS
User

Client System


System Security Lab

CPU

(conf. message)
OS
User (conf. message)

Client System


System Security Lab

CPU
4. show conf. message
+ request confirmation Browser 3. requests confirmation
(conf. message)
OS

Client System


System Security Lab

CPU
(conf. message)
5. confirm/abort OS

Client System


System Security Lab

CPU
(conf. message)
5. confirm/abort OS
confirm/abort

Client System


System Security Lab

CPU
(conf. message)
5. confirm/abort OS
6. attestation evidence:
confirm/abort - UTP Agent integrity measurement
Secure Execution Mode - conf. message from server
- confirm/abort from user
Client System


System Security Lab

CPU
(conf. message)
5. confirm/abort OS
Client System

Uni-directional Trusted Path


System Security Lab

CPU 7. accept/discard
(conf. message)
5. confirm/abort OS
Client System


System Security Lab

(conf. message)
5. confirm/abort OS
User 6. attestation evidence:
I/O Devices
- UTP Agent integrity measurement
Client System


System Security Lab

(conf. message)
5. confirm/abort OS
8. show result
I/O Devices
- UTP Agent integrity measurement
Client System


System Security Lab

Security Considerations
• Transaction generated by malware

CPU

(conf. message)
OS

Client System


System Security Lab


CPU

unexpected (conf. message)
(conf. message) OS

Client System


System Security Lab


CPU

unexpected (conf. message)
(conf. message) OS
User will notice
Client System
(unexpected transaction)


System Security Lab

• Transaction manipulation + manipulated UTP agent

CPU
1. issues
transaction Browser 3. requests confirmation
(conf. message)
OS
User

Client System


System Security Lab


CPU
1. issues
(conf. message)
OS

Client System


System Security Lab


CPU
1. issues
expected (conf. message)
(conf. message) OS

Client System


System Security Lab


CPU
1. issues
(conf. message) OS
User (conf. message) 6. attestation evidence:
I/O Devices UTP Agent - UTP Agent integrity measurement
- conf. message from server
Client System


System Security Lab


CPU
1. issues
(conf. message) OS
User (conf. message) 6. attestation evidence:
I/O Devices UTP Agent - UTP Agent integrity measurement
- conf. message from server
Client System
Server will notice and reject
(UTP integrity violation)


System Security Lab

• Transaction manipulation + faked confirmation dialog

CPU
1. issues
(conf. message)
OS
User
I/O Devices

Client System


System Security Lab


CPU
1. issues
(conf. message)
4. faked conf. OS
message Untrusted Execution Mode Server
User
I/O Devices

Client System


System Security Lab


CPU
1. issues
(conf. message)
4. faked conf. OS
I/O Devices
- ???

Client System


System Security Lab


CPU
1. issues
(conf. message)
4. faked conf. OS
I/O Devices
- ???

Client System Server will notice and reject
(no UTP execution)


System Security Lab

Setup: Device Enrollment
• Server knows that a human confirmed a transaction

• But how does the server know which user?

• Solution: binding the device to the user account

• Requires to register user devices in a setup phase
• Establishes a cryptographic credential to perform login
(e.g. public key protected by Secure Execution Mode)

• Protects against misuse of stolen account data!
• Attackers cannot use data (e.g. credit card number) because
their devices are not registered with that account at the server


Realization of UTP


System Security Lab

PC-Based Implementation
• Evidence attestation: Trusted Platform Module (TPM)

• Hardware root of trust (secure storage for keys; cryptographic operations)

• PCRs: registers that can be extended with integrity measurements of code

• Attestation: cryptographic signature of PCRs with a TPM-protected key

• Secure Execution Mode: Intel Trusted Execution Technology (TXT)

• Late Launch creates dynamic root of trust (DRTM)

• Reinitializes CPU and memory controller into known-good state

• Resets dynamic PCRs of the TPM (only CPU can reset these registers)

• Software framework: Flicker

• Allows to execute very small code in DRTM mode (without any OS)

• During DRTM mode, normal OS is halted; after switch back, OS is resumed


System Security Lab

Implementation Architecture
Client Server
CPU (Intel TXT)
Webserver
Web Browser Application
HTTPS
Script Extension
Extension

Client Utility Program Verification Program

Flicker
OS Launch

CPU Secure Mode

UTP Agent

TPM


System Security Lab

Client Server
CPU (Intel TXT)
Webserver
HTTPS
Script Extension
Extension


Flicker
OS Launch

CPU Secure Mode
+ 488
UTP Agent LOC

TPM


System Security Lab

Client Server
CPU (Intel TXT)
Webserver
HTTPS
Script Extension

}
Extension
+ 956 LOC
(non-TCB)

Flicker
OS Launch

CPU Secure Mode
+ 488
UTP Agent LOC

TPM


System Security Lab

Client Server
CPU (Intel TXT)
Webserver
HTTPS
Script Extension

}
Extension
+ 956 LOC
(non-TCB)

Flicker
OS Launch

CPU Secure Mode
+ 488
UTP Agent 2335 LOC LOC
(TCB)

TPM


System Security Lab

Screenshot (Transaction Initiation)


System Security Lab

Screenshot (Transaction Confirmation)


System Security Lab

Evaluation
• Code complexity:

• Very small total TCB: 2335 LOC (seL4 about 9000 [Klein et al. SOSP 2009])

• Including VGA and PS/2 keyboard driver (USB would add another 2000)

• Deployment:
• Server-side: only minor modifications necessary

• Client-side: users just need to download UTP software

• Performance:

• Switching time about 1 sec

• Remaining actions: waiting for user input, or in untrusted mode

• Usability:

• Confirmation message should not be simply "Press OK" (user tend to ignore)

• UTP is generic, confirmation message can be provided by service providers


System Security Lab

Conclusion
• Existing solutions against transaction generators are
inconvenient or not widely deployed

• Our proposal: a one-way trusted path to enable
service providers to gain assurance about user-
initiated transactions

• Realization based on on-demand isolated execution
environment and temporal control of user I/O devices

• Very small TCB and compatible to existing software

• Deployable on commodity systems today


System Security Lab

Questions?
Contact:

Marcel Winandy
Ruhr-University Bochum
marcel.winandy@trust.rub.de
http://www.trust.rub.de
Twitter: @mwinandy


BACKUP


System Security Lab

Implementation of UTP with Flicker


Uni-directional Trusted Path: Transaction Confirmation on Just One Device

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Uni-directional Trusted Path: Transaction Confirmation on Just One Device

Ähnlich wie Uni-directional Trusted Path: Transaction Confirmation on Just One Device (20)

Mehr von Marcel Winandy

Mehr von Marcel Winandy (12)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Uni-directional Trusted Path: Transaction Confirmation on Just One Device