SECURE IDENTIFICATION of ACTIVELY EXECUTED CODE on a GENERIC TRUSTED COMPONENT BRUNO VAVALA CMU / UL Nuno Neves Peter Steenkiste UL CMU IEEE/IFIP Conference on Dependable Systems & Networks (DSN’16)
outline Trusted Practical Executions: Analysis trends & tradeoffs Conclusions Identifying Problem Actively definition Executed Code
Anatomy of a Trusted Execution untrusted third party client Execute Bruno Vavala - IEEE/IFIP DSN'16 3 / 42
Anatomy of a Trusted Execution secure environment Load & Execute Attest Identify untrusted third party client Outsource Verify Bruno Vavala - IEEE/IFIP DSN'16 4 / 42
Anatomy of a Trusted Execution secure environment Load & Execute Attest Identify untrusted third party client • Code must have an ID (i.e. hash) • Trusted hardware computes ID Outsource V erify • Hardware attests the ID • Client trusts hardware & ID Bruno Vavala - IEEE/IFIP DSN'16 5 / 42
Generic TCC Interface • execute • code loading + identification + isolated execution • attest • TCC-signed code identity and I/O data • auth_put UTP-side • secure storage for a specific recipient (TCC authenticates the sender) • auth_get • secure storage from a specific sender (TCC authenticates the recipient) Implementable with: • Intel TXT + TPM • verify client-side • Hypervisor-based TCC • Intel SGX • … Bruno Vavala - IEEE/IFIP DSN'16 6 / 42
Trends Static Root of TOCTOU Dynamic Root Fast Trusted Large Trusted Trust: a system Problem: static of Trust: build Computing: Executions: is able to boot measurements a new robust combine slow implement in a verifiable do not reflect and verifiable trusted chips large services trusted state. later changes. chain of trust with software in the trusted on demand. on main CPU. environment. [2004] [2005-] [2008] [2010-] [2011-] Now timeline Richer Reduced On-demand Improved +security services in TCB execution efficiency +efficiency TCB Bruno Vavala - IEEE/IFIP DSN'16 7 / 42
Security/Efficiency Tradeoff for Large-Scale Services high identify-once- ? execute-once security identify-once- execute-forever low efficiency high Bruno Vavala - IEEE/IFIP DSN'16 8 / 42
outline Trusted Practical Executions: Analysis trends & tradeoffs Conclusions Identifying Problem Actively definition Executed Code
Code Identity /* SQLite code */ 1 0 1 0 1 0 1 1 1 0 1 0 0 1 0 0 1 0 1 1 int main () { 1 0 1 0 1 1 1 0 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 1 0 1 0 1 0 0 1 0 0 0 1 1 1 1 1 1 switch(op) { 1 1 1 0 1 0 1 1 1 1 0 1 0 1 0 0 0 1 0 1 1 1 0 1 0 1 1 1 1 0 1 0 1 1 1 1 1 1 0 1 case SELECT: 0 1 0 1 1 1 0 1 0 1 0 1 1 1 1 1 1 0 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 do_select(); 1 0 1 1 1 1 0 1 1 0 1 0 1 1 1 1 1 0 1 0 1 0 1 0 1 0 1 1 0 1 1 0 1 0 0 0 0 1 0 1 1 1 1 1 1 0 1 1 0 1 1 1 1 1 1 0 1 0 1 0 1 1 1 1 0 1 0 0 1 0 1 1 1 0 0 1 1 0 1 0 case DELETE: 0 1 1 0 1 0 1 1 1 0 1 0 1 0 1 1 0 1 0 0 1 0 1 1 1 0 1 0 0 1 0 0 0 1 0 0 1 0 1 0 do_delete(); 0 1 0 1 1 1 1 1 0 1 1 0 0 0 1 1 1 0 1 1 COMPILE IDENTIFY 1 1 0 1 1 1 1 0 1 0 1 0 0 1 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 1 1 0 1 1 0 1 1 1 0 0 1 0 1 0 1 0 0 1 1 0 1 0 1 1 0 1 0 0 1 1 case INSERT: 1 1 1 1 0 1 0 0 0 1 1 0 0 1 0 0 1 0 1 0 1 1 0 0 1 1 0 1 1 0 1 0 0 1 0 1 1 0 1 0 do_insert(); 1 0 1 0 1 0 1 1 1 0 1 0 0 1 0 1 0 1 0 1 SQLite 0 1 1 1 1 0 1 1 0 0 1 0 0 0 1 0 0 1 0 1 . 1 0 0 1 0 1 0 1 1 0 1 0 0 1 0 0 1 1 0 1 1 1 1 0 1 1 0 1 0 0 1 0 0 0 1 0 1 0 1 0 . 1 1 0 1 0 1 1 0 1 0 0 1 0 0 0 1 1 0 0 1 1 0 1 0 1 1 0 1 0 0 1 0 0 0 1 0 0 0 0 0 case FOOBAR: 0 1 1 0 1 0 1 1 1 0 1 0 0 1 0 0 1 1 1 0 1 1 1 0 1 1 1 0 1 0 0 1 0 0 1 1 1 0 0 1 do_foobar(); 1 1 0 1 0 0 1 0 0 1 0 0 0 1 1 1 0 1 1 0 } 1 0 1 0 1 1 0 1 0 0 1 0 0 0 1 0 1 0 0 0 0 1 1 0 1 0 1 1 1 0 1 0 0 1 0 0 0 1 1 1 source code code identity binary Bruno Vavala - IEEE/IFIP DSN'16 10 / 42
Execution Verification 1 0 1 0 1 0 1 1 1 0 1 0 0 1 0 0 1 0 1 1 1 0 1 0 1 1 1 0 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 1 0 1 0 1 0 0 1 0 0 0 1 1 1 1 1 1 1 1 1 0 1 0 1 1 1 1 0 1 0 1 0 0 0 1 0 1 1 1 0 1 0 1 1 1 1 0 1 0 1 1 1 1 1 1 0 1 0 1 0 1 1 1 0 1 0 1 0 1 1 1 1 1 1 0 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 0 1 1 1 1 0 1 1 0 1 0 1 1 1 1 1 0 1 0 1 0 1 0 1 0 1 1 0 1 1 0 1 0 0 0 0 1 0 1 1 1 1 1 1 0 1 1 0 1 1 1 1 1 1 0 1 0 1 0 1 1 1 1 0 1 0 0 1 0 1 1 1 0 0 1 1 0 1 0 0 1 1 0 1 0 1 1 1 0 1 0 1 0 1 1 0 1 0 0 1 0 1 1 1 0 1 0 0 1 0 0 0 1 0 0 1 0 1 0 0 1 0 1 1 1 1 1 0 1 1 0 0 0 1 1 1 0 1 1 VOUCHES 1 1 0 1 1 1 1 0 1 0 1 0 0 1 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 1 1 0 1 1 0 1 1 1 0 0 VERIFIES 1 0 1 0 1 0 0 1 1 0 1 0 1 1 0 1 0 0 1 1 FOR 1 1 1 1 0 1 0 0 0 1 1 0 0 1 0 0 1 0 1 0 1 1 0 0 1 1 0 1 1 0 1 0 0 1 0 1 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 0 0 1 0 1 0 1 0 1 0 1 1 1 1 0 1 1 0 0 1 0 0 0 1 0 0 1 0 1 1 0 0 1 0 1 0 1 1 0 1 0 0 1 0 0 1 1 0 1 SQLite 1 1 1 0 1 1 0 1 0 0 1 0 0 0 1 0 1 0 1 0 1 1 0 1 0 1 1 0 1 0 0 1 0 0 0 1 1 0 0 1 1 0 1 0 1 1 0 1 0 0 1 0 0 0 1 0 0 0 0 0 client 0 1 1 0 1 0 1 1 1 0 1 0 0 1 0 0 1 1 1 0 1 1 1 0 1 1 1 0 1 0 0 1 0 0 1 1 1 0 0 1 1 1 0 1 0 0 1 0 0 1 0 0 0 1 1 1 0 1 1 0 1 0 1 0 1 1 0 1 0 0 1 0 0 0 1 0 1 0 0 0 0 1 1 0 1 0 1 1 1 0 1 0 0 1 0 0 0 1 1 1 executed attested identity code Bruno Vavala - IEEE/IFIP DSN'16 11 / 42
Identified ≠ Executed 1 0 1 0 1 0 1 1 1 0 1 0 0 1 0 0 1 0 1 1 1 0 1 0 1 0 1 1 1 0 1 0 0 1 0 0 1 0 1 1 1 0 1 0 1 1 1 0 1 0 0 1 0 0 0 1 1 0 1 0 1 0 1 0 1 1 1 0 1 0 0 1 0 0 0 1 1 0 1 0 0 1 1 1 0 1 0 1 0 0 1 0 0 0 1 1 1 1 1 1 0 1 1 0 1 0 1 1 1 0 1 0 0 1 0 0 0 1 1 1 > 0 1 1 1 0 1 0 1 0 0 1 0 0 0 1 1 1 1 1 1 1 1 1 0 1 0 1 1 1 1 0 1 0 1 0 0 0 1 0 1 1 1 1 0 1 0 1 1 1 1 0 1 0 1 0 0 0 1 0 1 1 1 0 1 0 1 1 1 1 0 1 0 1 1 1 1 1 1 0 1 1 1 0 1 0 1 1 1 1 0 1 0 1 1 1 1 1 1 0 1 0 1 0 1 1 1 0 1 0 1 0 1 1 1 1 1 1 0 1 0 0 1 0 1 1 1 0 1 0 1 0 1 1 1 1 1 1 0 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 0 1 1 1 1 0 1 1 0 1 0 1 1 1 1 1 0 1 0 1 0 1 1 1 1 0 1 1 0 1 0 1 1 1 1 1 0 1 0 1 0 1 0 1 0 1 1 0 1 1 0 1 0 0 0 0 1 0 1 1 0 1 0 1 0 1 1 0 1 1 0 1 0 0 0 0 1 0 1 1 1 1 1 1 0 1 1 0 1 1 1 1 1 1 0 1 0 1 0 1 1 1 1 1 0 1 1 0 1 1 1 1 1 1 0 1 0 1 0 1 1 1 1 0 1 0 0 1 0 1 1 1 0 0 1 1 0 1 0 1 1 1 1 0 1 0 0 1 0 1 1 1 0 0 1 1 0 1 0 0 1 1 0 1 0 1 1 1 0 1 0 1 0 1 1 0 1 0 0 0 1 1 0 1 0 1 1 1 0 1 0 1 0 1 1 0 1 0 0 1 0 1 1 1 0 1 0 0 1 0 0 0 1 0 0 1 0 1 0 1 0 1 1 1 0 1 0 0 1 0 0 0 1 0 0 1 0 1 0 0 1 0 1 1 1 1 1 0 1 1 0 0 0 1 1 1 0 1 1 0 1 0 1 1 1 1 1 0 1 1 0 0 0 1 1 1 0 1 1 1 1 0 1 1 1 1 0 1 0 1 0 0 1 0 1 0 1 0 0 1 1 0 1 1 1 1 0 1 0 1 0 0 1 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 1 1 0 1 1 0 1 1 1 0 0 1 0 1 0 0 1 0 1 0 1 1 0 1 1 0 1 1 1 0 0 1 0 1 0 1 0 0 1 1 0 1 0 1 1 0 1 0 0 1 1 1 0 1 0 1 0 0 1 1 0 1 0 1 1 0 1 0 0 1 1 1 1 1 1 0 1 0 0 0 1 1 0 0 1 0 0 1 0 1 0 1 1 1 1 0 1 0 0 0 1 1 0 0 1 0 0 1 0 1 0 1 1 0 0 1 1 0 1 1 0 1 0 0 1 0 1 1 0 1 0 1 1 0 0 1 1 0 1 1 0 1 0 0 1 0 1 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 0 0 1 0 1 0 1 0 1 1 0 1 0 1 0 1 1 1 0 1 0 0 1 0 1 0 1 0 1 0 1 1 1 1 0 1 1 0 0 1 0 0 0 1 0 0 1 0 1 0 1 1 1 1 0 1 1 0 0 1 0 0 0 1 0 0 1 0 1 1 0 0 1 0 1 0 1 1 0 1 0 0 1 0 0 1 1 0 1 1 0 0 1 0 1 0 1 1 0 1 0 0 1 0 0 1 1 0 1 1 1 1 0 1 1 0 1 0 0 1 0 0 0 1 0 1 0 1 0 1 1 1 0 1 1 0 1 0 0 1 0 0 0 1 0 1 0 1 0 1 1 0 1 0 1 1 0 1 0 0 1 0 0 0 1 1 0 0 1 1 1 0 1 0 1 1 0 1 0 0 1 0 0 0 1 1 0 0 1 1 0 1 0 1 1 0 1 0 0 1 0 0 0 1 0 0 0 0 0 1 0 1 0 1 1 0 1 0 0 1 0 0 0 1 0 0 0 0 0 0 1 1 0 1 0 1 1 1 0 1 0 0 1 0 0 1 1 1 0 0 1 1 0 1 0 1 1 1 0 1 0 0 1 0 0 1 1 1 0 1 1 1 0 1 1 1 0 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 1 1 1 0 1 0 0 1 0 0 1 1 1 0 0 1 1 1 0 1 0 0 1 0 0 1 0 0 0 1 1 1 0 1 1 0 1 1 0 1 0 0 1 0 0 1 0 0 0 1 1 1 0 1 1 0 1 0 1 0 1 1 0 1 0 0 1 0 0 0 1 0 1 0 0 0 1 0 1 0 1 1 0 1 0 0 1 0 0 0 1 0 1 0 0 0 0 1 1 0 1 0 1 1 1 0 1 0 0 1 0 0 0 1 1 1 identified actually executed binary code binary code Bruno Vavala - IEEE/IFIP DSN'16 12 / 42
Desirable Properties • Identifying what is “actually” executed • TCC agnostic execution • Keeping efficient client-side verification Bruno Vavala - IEEE/IFIP DSN'16 13 / 42
outline Trusted Practical Executions: Analysis trends & tradeoffs Conclusions Identifying Problem Actively definition Executed Code
Model Trusted Environment untrusted services trusted service OS TCC TPM/SGX hardware • OS and services are untrusted • Client knows service identity and TCC certificate Bruno Vavala - IEEE/IFIP DSN'16 15 / 42
Enriching the Interface • execute • code loading + identification + isolated execution • attest • TCC-signed code identity and I/O data • auth-put UTP-side • secure storage for a specific recipient (TCC authenticates the sender) • auth-get • secure storage from a specific sender (TCC authenticates the recipient) Implementable with: • Intel TXT + TPM • verify client-side • Hypervisor-based TCC • Intel SGX • … Bruno Vavala - IEEE/IFIP DSN'16 16 / 42
Recommend
More recommend