Verification of Low Verification of Low - - level Crypto level Crypto - - Protocol Implementations Using Protocol Implementations Using Automated Theorem Proving Automated Theorem Proving Jan Jan J J ü ü rjens rjens (contrib. Mark (contrib. Mark Yampolskiy Yampolskiy ) ) Software & Systems Engineering Software & Systems Engineering TU M TU M u u nich nich http://www4.in.tum.de/~ http://www4.in.tum.de/~ juerjens juerjens
43
Embed
Verification of Low-level Crypto- Protocol Implementations ...
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Verification of LowVerification of Low--level Cryptolevel Crypto--Protocol Implementations Using Protocol Implementations Using
Automated Theorem ProvingAutomated Theorem ProvingJan Jan JJüürjensrjens
(contrib. Mark (contrib. Mark YampolskiyYampolskiy))
Software & Systems EngineeringSoftware & Systems EngineeringTU MTU Muunichnich
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 4
Model-based Security Engineering
• Analyze (UMLsec) models against securityrequirements.
• Generate code (or tests) from models.
• Generate models fromevolving or legacy code.
Goal: model-based = source-code based.
Requirements
Models
Requirements
Models
CodeCode
Analyze
Codegen.Testgen.
Modelgen./Reverse E.
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 5
Security Analysis of C-Programs
Goal: Logic-based security verification of C programs which is as
• automatic and• completeas possible. Note: can‘t be both perfectly automated and
complete: Security in general undecidable.Here: emphasize automation.
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 6
Crypto-Hardware API‘s (PKCS 11)
Here: support correct use of PKCS 11 API‘s.Keep track of session handles.C_GetAttributeValue obtains attribute valueC_SetAttributeValue modifies attribute valueC_Encrypt encrypts single-part data C_Decrypt decrypts encrypted dataC_Digest digests single-part dataC_Sign signs single-part data C_VerifyRecover verifies signature, data recoveredC_GenerateKey generates a secret keyC_GenerateKeyPair generates a key pairC_GenerateRandom generates random data
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 7
Security Analysis
Following Dolev, Yao (1982): To analyze system, verify against attacker model from threat scenarios in deployment diagrams who
• may participate in some protocol runs,• knows some data in advance,• may intercept messages on some links,• injects messages that it can produce in some
links• may access certain nodes.
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 8
Adversary: Simulation
A BAdversary
m(x)
Adversaryknowledge:
k-1, y,
m(x)
x
return({z}k)
[argb,1,1 = x]
{z}k, z
return({y::x}z)
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 9
Generate control flowgraph (e.g. with aicall(Absint, Germany)).
Transform to Mealy Machines:trans (state,inpattern,condition,action,nextstate)where action can be outpattern or
localvar:=value.Translate to abstract interpretation in FOL
formula.
Control Flow Graph
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 10
Security Analysis in First-order Logic
Approximate set of possible data valuesflowing through system from above.
Predicate knows(E) meaning that the adversary may get to know E during the execution of the protocol.
E.g. secrecy: For any secret s, check whether can derive knows(s) using automated theorem prover.
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 11
Cryptographic Expressions IExp: quotient of term algebra generated from
sets Data, Keys, Var of symbols using• _::_ (concatenation), head(_), tail(_),• (_)-1 (inverse keys)• { _ }_ (encryption)• Dec_( ) (decryption)• Sign_( ) (signing)• Ext_( ) (extracting from signature)
(each w. session parameter) and equations:
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 12
Cryptographic Expressions II
• ∀E,K,S,S’,S’’.DecK;S’’-1({E;S}K;S’)=E
• ∀E,K,S,S’,S’’.ExtK(SignK;S‘‘-1(E;S);S‘)=E
• ∀E1,E2,,S,S’.head(E1::SE2;S’)=E1
• ∀E1,E2,S,S’.tail(E1::SE2;S’)=E2
Write E1::E2::E3 for E1::(E2::E3) and fst(E1::E2) for head(E1::E2) etc.
Can include further crypto-specific primitives and laws (XOR, …).
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 13
First-order Logic: Basic Rules
Define knows(E) for any E initially known to the adversary.
For evolving knowledge define∀ E1,E2,S.(knows(E1)∧ knows(E2) �
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 17
Preprocessing of code
For simplification and efficiency apply semantics-preserving transformations to the C program:
• use of single-assignment variables• eliminate side effects• factor out pointer arithmeticAnalyze loops up to a fixed number of iterations.
No so much of a restriction when analyzingsecure interactions in crypto protocols.
Include annotations to abstract cryptofunctions etc.
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 18
Client I
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 19
Client II
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 20
Surprise …
� Completely insecure wrt stated goals.
But why ? Use prolog-based attack generator.
Can derive knows(s). That is: Protocol does not preserve secrecy of s against adversaries.
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 21
Man-in-the-Middle Attack
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 22
Biometric Authentication System
In development by large German company.
In joint project, use presented securityanalysis tools at given UML specification.
So far, have discovered three major attacksagainst subsequently improved versions(misuse counter circumvented by dropping / replaying messages, smart-card insufficientlyauthenticated by recombing sessions).
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 23
Conclusions
Code security verification using assertions:• formally based approach• automated tool support• industrially used programming language• integrated approach (specifications, source-
code, configuration data)Future:• Virtual C execution machine in tptp instead of
manual code tptp annotations…
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 24
Resources
TUM TB Dez. ‘04 (with T. Kuhn)International Conference for
Software Maintenance 2005Models / UML 2005 (with S. Houmb)
More information (papers, slides, tool, …): http://www4.in.tum.de/~juerjens
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 25
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 26
Abstraction
Enable efficient automated analysis byabstraction (e.g. functions or code-blocks):
• symbolic representation of cryptographic orarithmetic routines
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 29
TLS Overview
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 30
Client I
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 31
Client IIconst_c_cert_ca
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 32
Server I
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 33
Server II
const_s_cert_ca
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 34
The Fix
e-Setheo: knows(s) not derivable. Thus „secure“ in above sense.
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 35
Interpretation
Why examine knows(s) rather than secret(s) ?�Really only care about initial models of the
axioms (basic axioms, protocol axioms and initial adversary knowledge) - our „idealizedimplementation“. Models basic assumptionson the security of the cryptographicalgorithms (viewed at our level of abstraction): Cryptographic data does notfulfill any unintended equations (or theadversary cannot learn these).
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 36
Modular Verification: Idea
For given protocol try to establish assertions
a1 � g1 .Include into C code as annotations.Check whether axioms together with
annotations entail threat conjecture.
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 37
Modular Verification: Example
If for protocol p1, basic axioms, protocol axiomsand initial adversary knowledge entails knows(s) (have counter-example) then in the initial modelsatisfying these axioms (our „idealizedimplementation“) the adversary can learn s.
We generate the assertioninit_knowledge_axioms � knows(s)
(Careful: cannot just generate … � not(knows(s)) otherwise without possible inconsistency.)
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 38
Mutual authentication withchallenge & response
Generate shared key
Forged smart-card after authentic.; replay old session key
Modular Verification: Application
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 39
Control Flow graph to State Machine
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 40
CFG to State Machine I
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 41
CFG to State Machine II
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 42
TLS Variant in TPTP notation I
Jan Jürjens, TU Munich: Verification of Crypto-Protocol Implementations 43