first year review project overview -...
TRANSCRIPT
2
Computing/Networking Convergence
• Exponential growth in computing/networking
• Leads to unifying: computing/networking
• All machines are interconnected
• Ensuring that applications are TRUSTED is critical [Operating as specified]
• Avoiding manipulation of programs/protocols
• STEALING content and information
• DENIAL of service – TCP example
• FAIR on-line bidding/trading/gaming
• … … …
3
Remote Entrusting: Design Objective
• How a remote code (SW application) on a
1st untrusted machine
can be entrusted by a
• 2nd entrusting machine?”[albeit running inside an untrusted environment]
• I.e., Distribution of trust
or entrusting
4
���������
�� �����������������
���������� ����������������
�������������������
• 1st Untrusted machine emanates Secure Tags
from a code/software during execution
• 2nd Entrusting Machine is ENTRUSTING the
• 1st Untrusted machine by verifying the Secure Tags
��������������������������������������
Core of Trust
5
Informal Definition of Trust
for Remote Entrusting
•• A software is deemed authentic/trustedA software is deemed authentic/trusted
if and only if its functionality if and only if its functionality
has not been altered/tampered by an has not been altered/tampered by an
untrusted/unauthorized entityuntrusted/unauthorized entity
prior to or during executionprior to or during execution
6
Scope of Trust in RE-TRUST
Human-to-Human
Machine-to-MachineRemote Entrusting:
RemoteSW Authentication
In Run-time
• Trust necessary condition: some sort of “identity”
Signature/attestation/authentication
of SW & HW in run-time
•• { Informally: avoidance of the { Informally: avoidance of the ””manman--atat--thethe--
endend”” attack [i.e., the untrusted user] } attack [i.e., the untrusted user] }
7
Challenges of the Basic Approach1.1. Combining/interlocking of two programsCombining/interlocking of two programs
• 1. Functional code to be entrusted
• 2. Secret (code, parameters-keys) –for secure tag generator
2.2. Tamper resistance (TR) of the aboveTamper resistance (TR) of the aboveVarious methods – “lines of defense”:
• TR in SW only
• Replacement
• TR in SW/HW (e.g., TC, smart card)
8
Quality of Remote Entrusting
SW and SW/HW Methods[Frequency and RE Complexity]
Method 2: SWComponents/Parameters
Replacement
(increased frequency)
Method 1: SWTamper-resistance (TR) Quality
(increased reverse engineering (RE) complexity)
Improved Security & TrustImproved Security & Trustis Measured by IncreasedDistance from the Origin
Method 3: SW/HW [e.g., USB Smart Card]Tamper-resistance (TR) Quality
(increased reverse engineering (RE) complexity)
9
Some Current Approaches
1. Sending packetsBased on monitoring & diagnosticsreactive (after the fact)
• Firewall monitoring
• SLA (service level agreement) policing
2. Receiving packets (e.g., content)Based on adding special HW
• E.g., TC/NGSCB, “watch-dogs,” …
• Specific to each computer HW depends on configuration, architecture, …
• What to do with current systems?
10
TCG Architecture
• Trusted Platform Module (TPM)The set of functions and data that are common to all types of platform, which must be trustworthy if the Subsystem is to be trustworthy; a logical definition in terms of protected capabilities and shielded locations.
CPU
RAM
Controller
Display
Boot ROM
TPM
DevicesEmbedded
RemovableDevices
Reference PC Platform containing TCG TPM
Tamper ProofComputing Device
CPU exec boot TCG ROMTPM is not snooping –but respond to requests
11
TCG: TPM Architecture
Communications
Non−Volatile
Storage
Platform
Configuration
Register (PCR)
Attestation
Identity
Key (AIK)
Program
Code
I/O
RSA
Engine Opt−InExec
Engine
Key
GenerationSHA−1
Engine
Random
Number
Generator
Trusted Platform Module (TPM)
TPM Component Architecture
PCR stores hash of measurementvalues but is not visible outside TPMWhile “chaining” measurements
12
TCG: Transitive Trust
Application Code
OS Code
OS Loader Code
CRTM
TBB + Roots of Trust
1
3
5
2
4
6
Execution Flow
Measurement Flow
Transitive Trust applied to Boot from Static Root of Trust
Primary Objective:Application Trust
TBB - trusted buildin blockCRTM - core root of trust for measurementsNote:OS etc. updates should be known to the verifier--- open-source? --- customization?For apps "big brother" on "mother board“?Consequently - closed computing system?
- users cannot do what they want?!
13
TCG: Integrity Reporting• RTR – root of trust reporting has two functions
1. expose shielded locations for storage of integrity measurements2. attest to the authenticity of stored values based on trusted platform identities
1. RequestPlatformConfiguration( )
2. GetEventLog( )
3. GetSignedPCR( )
4. SignPCRValue( )
5. GetPlatformCredentials( )
PlatformConfiguration( )
6. ValidatePlatformCredentials( )
SignedPCR( )
ChallengerPlatform
Agent TPM Repository
Attestation Protocol and Message Exchange
Credentials: certificate that are built in the machine e.g., processor ID, TPM ID,
EK public key –endorsement key for generating attestation keys
“TrustedChecker”
Non Run-time “Secure-TagGenerator”
Attestation: provides signaturesto the challenger "like" remote entrusting
14
TC vs. RE-TRUST• Core of trust
• TC: local
• RE-TRUST: remote
• Run-time
• TC: no
• RE-TRUST: yes
• Scope of entrusting
• TC: bottom - up
• RE-TRUST: selected applications
• Trust authority
• TC: external (TPM is based on public-key)
• “Big-brother” on the motherboard!?
• RE-TRUST: none / mutual agreement
15
Trusted Tag
Checker (TC)
Untrusted Computing
Environment
TrustedFlow
Generator (TG)
Handheld/Wireless Device
Trusted Tag
Checker (TC)
TrustedFlow
Generator (TG)
Untrusted Computing
Environment
Handheld/Wireless Device Network Interface
������������ �������������������
���������
���������
��������
��������
16
TG
TG
TG
TG
TGTG
TGTG
TC
TC TC
TC
Entrusting
Entrusting Entrusting
Entrusting
TC
“Castle”
“HARDENED”with SpecialHardware/Software(e.g., TCPA)
�������������!������ �������������������
���������
��������� ���������
17
Selected Scientific and Technical Challenges
1. SW-based – Tamper-resistance quality
• Combining two programs: original together with tag generator into “secure SW module”.
• Protecting the secure SW so it is hard to separate by increased program cohesiveness.
• Hiding the semantic of the secure SW module by means of obfuscation, for example.
• Measuring the complexity of reverse engineering of the secure SW module.
2. SW-based – Dynamic replacement
• Replacement of SW component in run-time is different from the current operating system (OS) paradigm.
• Replacement of SW component while resisting tampering by the OS is a new challenge.
• Analyzing trade-off between dynamic replacement frequency and tamper-resistance quality.
3. HW/SW-based – Tamper-resistance and encryption quality
• Tamper-resistant co-design of applications with software and hardware components.
• Analyzing trade-off between hardware and software.
• The security of communication between the secure SW module and the HW component.
18
Work Plan Organization
WP1: Overall Architecture
WP2: SW-basedTR Method 1 & 2
WP3: HW/SW-basedTR Method 3
WP4: Security/Trust Analysis
Optional (analysis dependent):- Proof-of-concepts (PoC) – WP2/WP3 - Standardization – WP1 - Solution definitions / technology transfer – WP1
Analysis
Analysis Analysis
Analysis
Analysis
19
Work-planning and timetable – Gantt0 3 6 9 12 15 18 21 24 27 30 33 36
WP0 - Management and Coordination
T0.1 Management activities
T0.2 Risk management activitiesT0.3 Scientific/industrial advisory board activities
WP1 - Architectural Framework
T1.1 – Trust requirements, generic applications
T1.2 – SW-based initial architectural framework
T1.3 – HW/SW-based initial architectural framework
T1.4 – SW-based reference architecture designT1.5 – HW/SW-based reference architecture design
WP2- SW-based Tamper Resistance
T2.1 – Trust model
T2.2 – Secure interlocking and authenticity checking
T2.3 – Dynamic replacement
T2.4 – Increased reverse engineering complexity
T2.5 – Design of entrusting protocol T2.6 – Proof of concept
WP3 - HW/SW-based Tamper Resistance
T3.1 – Trust model
T3.2 – Hardware/Software co-obfuscation
T3.3 – Encrypted code execution
T3.4 – Observable cryptography T3.5 – Scalability and performance
WP4 - Trust and Security Analysis
T4.1 – Trust analysis of SW-based method
T4.2 – Trust analysis of HW/SW-based method
T4.3 – Reverse engineering complexity
T4.4 – Comparative analysis with trusted computingT4.5 – Remote entrusting and Internet secure protocols
WP5 - Dissemination
T5.1 – Project oriented dissemination activities T5.2 – Scientific oriented dissemination activities
20
Initial architecture
WP1-Phase 1
DesignWP2/WP3
Analysis &Evaluation
WP4
Reference architecture
WP1-Phase 2
T1.2
SW-based
initial arch
T4.1- T43
Analysis of
SW-based method
and reverse
engineering
complexity
Task
Logicaldependency
T1.3
HW/SW-based
initial arch
Task1.4
SW-based
reference arch
Task1.5
HW/SW-based
reference arch
T4.2
Analysis of
HW/SW-based
method
T2.2- T2.3
Interlocking,
authenticity,
replacement
T2.4
Resistance to
reverse
engineering
T3.2
HW/SW
co-obfuscation
T3.3 – T3.4
Encrypted
code execution,
observable
cryptography
21
Work Package List
310TOTAL
536118P1
Dissemination,
Exploitation,
Standardization
WP 5
836175P1Trust and Security
AnalysisWP 4
536172P4HW/SW-based Tamper
Resistance MethodWP 3
736195P2SW-based Tamper
Resistance MethodsWP 2
536136P1Architectural
FrameworkWP1
636114P1Management and
CoordinationWP0
Delivera
ble
No.
End
month
Start
month
Person-
months
Lead
contractorWorkpackage titleNo.
22
Scientific/Industry Advisory Board
• Internationally renown experts in both academia and industry:
• Christian Collberg (University of Arizona)
• Amir Herzberg (Bar Ilan University, Israel)
• Willem Jonker (Philips Research)
• David Naccache (University Paris II)
• Bart Preneel (Katholieke Universiteit Leuven)
• Paolo Prinetto (Politecnico di Torino)
• Paul Van Oorschot (Carleton University, Canada)
• Moti Yung (Columbia University, USA)