RUN-TIME ATTACK DETECTION IN CRYPTOGRAPHIC APIS Marco Squarcina 1 , joint work with Riccardo Focardi 1 August 23, 2017 1 Università Ca’ Foscari Venezia (IT) / Cryptosense (FR) 30th IEEE Computer Security Foundations Symposium (CSF2017) Santa Barbara (CA), USA
OUTLINE • Background • Run-time monitor • Model • Analysis • Implementation • Conclusions 1
Background
CRYPTOGRAPHIC API 2
CRYPTOGRAPHIC API 2
CRYPTOGRAPHIC API 2
KEY MANAGEMENT 3 Host Machine Trusted Device
KEY MANAGEMENT 3 Host Machine Trusted Device E ( ) wrap
KEY MANAGEMENT 3 Host Machine Trusted Device E ( ) wrap E ( ) unwrap
KEY MANAGEMENT 3 Host Machine Trusted Device E ( ) wrap E ( ) unwrap
WRAP/DECRYPT ATTACK [Clu03] 4 Host Machine Trusted Device
WRAP/DECRYPT ATTACK [Clu03] 4 Host Machine Trusted Device genkey
4 WRAP/DECRYPT ATTACK [Clu03] Host Machine Trusted Device genkey E ( ) wrap
4 WRAP/DECRYPT ATTACK [Clu03] Host Machine Trusted Device genkey E ( ) wrap E ( ) decrypt
4 WRAP/DECRYPT ATTACK [Clu03] Host Machine Trusted Device genkey E ( ) wrap E ( ) decrypt
• Systems are rarely modiied SOLUTIONS Possible solutions • New cryptographic API [CS09] • Modiications to current standards [BCFS10] • Reduction of functionalities Dificult to deploy in practice • Legacy applications • Key management functionalities required 5
SOLUTIONS Possible solutions • New cryptographic API [CS09] • Modiications to current standards [BCFS10] • Reduction of functionalities Dificult to deploy in practice • Systems are rarely modiied • Legacy applications • Key management functionalities required 5
Run-time monitor
• Secure A NEW APPROACH Our proposal • Collect API invocation sequence for various devices • Analyse log to detect any leakage of sensitive keys Goals • Accurate • Distributed • Eficient 6
A NEW APPROACH Our proposal • Collect API invocation sequence for various devices • Analyse log to detect any leakage of sensitive keys Goals • Secure • Accurate • Distributed • Eficient 6
Model
CORE MODEL q 0 q 1 Generalisation of the DKS [DKS10] model 7 Wrap/Decrypt Attack • Labels on transitions ( actions ) to capture API calls • No PKCS#11 speciic features (attributes) • States represent user’s knowledge q 0 = { h k 1 , h k 2 } Wrap ( h k1 , h k2 ) − − − − − − − − → → q 1 q 1 = q 0 ∪ { E k 1 ( k 2 ) } Decrypt ( h k1 , E k1 ( k 2 )) − − − − − − − − − − − − → → q 2 q 2 = q 1 ∪ { k 2 }
q n is SK-secure SECURE LOCAL EXECUTION Dolev-Yao [DY83] model for attacker’s deduction capabilities • Given a set of sensitive keys SK we want to monitor • Executions can include attacker’s actions Deinition ( SK -Secure Execution) An execution is secure iff does not leak any of its secure key q 0 SK q n 8 ∈ SK • Attacker can enc/dec using known keys and keys /
SECURE LOCAL EXECUTION Dolev-Yao [DY83] model for attacker’s deduction capabilities • Given a set of sensitive keys SK we want to monitor • Executions can include attacker’s actions Deinition ( SK -Secure Execution) 8 ∈ SK • Attacker can enc/dec using known keys and keys / An execution σ is secure iff does not leak any of its secure key → ∗ q n is SK-secure α σ = q 0 − → ⇐ ⇒ SK ∩ q n = ∅
• Soundness • Completeness SECURE EXECUTION Proposition (characterization of insecure executions) • Wrap of a sensitive key under a key not in SK Implications • Only Wrap and Decrypt API calls must be monitored no false attacks detected all attacks are spotted 9 An execution σ is SK -secure iff none of the following is in σ • Decrypt of a sensitive key encrypted under a sensitive key
SECURE EXECUTION Proposition (characterization of insecure executions) • Wrap of a sensitive key under a key not in SK Implications • Only Wrap and Decrypt API calls must be monitored 9 An execution σ is SK -secure iff none of the following is in σ • Decrypt of a sensitive key encrypted under a sensitive key • Soundness → no false attacks detected • Completeness → all attacks are spotted
Wrap h k1 h k2 h k 1 h k 2 E k 1 k 2 Decrypt h k1 E k1 k 2 h k 1 E k 1 k 2 is k 1 k 2 -secure, is k 1 -secure but not k 1 k 2 -secure! SECURE DISTRIBUTED EXECUTION k 2 q 1 q 1 q 0 q 1 q 1 Deinition (Secure Distributed Executions) q 0 Distributed Wrap/Decrypt Attack with their respective sets of sensitive keys. 10 S = { ( SK 1 , σ 1 ) , . . . , ( SK n , σ n ) } is a set of distinct executions Let SK = � i = 1 ,..., n SK i . S is secure ⇐ ⇒ σ 1 , . . . , σ n are SK -secure
SECURE DISTRIBUTED EXECUTION Distributed Wrap/Decrypt Attack 1 0 Deinition (Secure Distributed Executions) 10 with their respective sets of sensitive keys. S = { ( SK 1 , σ 1 ) , . . . , ( SK n , σ n ) } is a set of distinct executions Let SK = � i = 1 ,..., n SK i . S is secure ⇐ ⇒ σ 1 , . . . , σ n are SK -secure Wrap ( h k1 , h k2 ) σ = q 0 − − − − − − − − → → q 1 q 1 = { h k 1 , h k 2 } ∪ { E k 1 ( k 2 ) } Decrypt ( h k1 , E k1 ( k 2 )) σ ′ = q ′ → q ′ q ′ − − − − − − − − − − − − → 1 = { h k 1 , E k 1 ( k 2 ) } ∪ { k 2 } σ is { k 1 , k 2 } -secure, σ ′ is { k 1 } -secure but not { k 1 , k 2 } -secure!
Analysis
k 2 is leaked but cannot be linked to one of the handles! • Terms can only be compared by syntactic equality KeyFprint kf y , y LOG ANALYSIS PROBLEM Distributed Wrap/Decrypt Attack (Partial Execution) kf y kf y y kf y , y • h y • Enrich logs with a special one-way deterministic function Key Fingerprint k 1 11 0 σ = q 0 q 0 = { h k 1 , h k 2 } Decrypt ( h k1 , E k1 ( k ? )) σ ′ = q ′ → q ′ q ′ − − − − − − − − − − − − → 1 = { h k 1 , E k 1 ( k ? ) } ∪ { k ? }
• Terms can only be compared by syntactic equality KeyFprint kf y , y LOG ANALYSIS PROBLEM Distributed Wrap/Decrypt Attack (Partial Execution) kf y kf y y kf y , y • h y • Enrich logs with a special one-way deterministic function Key Fingerprint 1 11 0 σ = q 0 q 0 = { h k 1 , h k 2 } Decrypt ( h k1 , E k1 ( k ? )) σ ′ = q ′ → q ′ q ′ − − − − − − − − − − − − → 1 = { h k 1 , E k 1 ( k ? ) } ∪ { k ? } k ? = k 2 is leaked but cannot be linked to one of the handles!
LOG ANALYSIS PROBLEM Distributed Wrap/Decrypt Attack (Partial Execution) KeyFprint • h y • Enrich logs with a special one-way deterministic function • Terms can only be compared by syntactic equality Key Fingerprint 1 11 0 σ = q 0 q 0 = { h k 1 , h k 2 } Decrypt ( h k1 , E k1 ( k ? )) σ ′ = q ′ → q ′ q ′ − − − − − − − − − − − − → 1 = { h k 1 , E k 1 ( k ? ) } ∪ { k ? } k ? = k 2 is leaked but cannot be linked to one of the handles! → kf ( y ) , y ′ → kf ( y ′ ) , y = y ′ ⇐ ⇒ kf ( y ) = kf ( y ′ ) − − − − −
LOG ANALYSIS USING KEY FINGERPRINTING Given logs and handles of sensitive keys: 1. Collect all the ingerprints of sensitive keys ATTACK • if the decryption key is sensitive • compute the ingerprint of the result and compare it against the set of ingerprints collected at step 1 12 2. For each wrap call • if a sensitive key is wrapped under an insecure one → 3. For each decrypt call • if a match is found → ATTACK
Implementation
LOG ANALYSIS TOOL FOR PKCS#11 The tool is able to detect all the key-management attacks found in the literature [DKS10, FLS10] involving symmetric encryption operations 13
• encrypt kf k E r E k r • decrypt kf k D r D k r • wrap kf k W E k k LOG ANALYSIS TOOL FOR PKCS#11 Instrumented API functions Possible ingerprints for a key depending on its attributes • C_Login • C_GenerateKey • C_GetAttributeValue • C_Decrypt • C_WrapKey 14
LOG ANALYSIS TOOL FOR PKCS#11 Instrumented API functions • C_WrapKey • C_Decrypt • C_GetAttributeValue • C_GenerateKey • C_Login Possible ingerprints for a key depending on its attributes 14 • encrypt → kf ( k ) E = � r , E k ( r ) � • decrypt → kf ( k ) D = � r , D k ( r ) � • wrap → kf ( k ) W = � E k ( k ) �
Conclusions
CONTRIBUTIONS • Provided a model for distributed run-time detection of crypto APIs attacks • Devised a sound and complete characterization of attacks • Proved that the problem of ofline attack detection is unsolvable • …but key ingerprinting mechanism enables feasible and eficient analysis • Developed a proof-of-concept log analysis tool for PKCS#11 15
FUTURE WORKS • Reason about practical implementations of key ingerprint • Cover a more extensive fragment of PKCS#11 with the tool and implement a key ingerprint call the API using software emulators • Characterize other crypto APIs and study formally which are the problematic rules that should be tracked in the logs • Formally devise a logging policy to prevent logs to grow indeinitely 16
Recommend
More recommend
