1
|
- Ge Zhu
- Akhilesh Tyagi
- Iowa State University
|
2
|
- Many definitions of trust.
- Typically transaction level trust propagation/policy.
- Self-assessment of trust.
- A trust policy & security policy specification.
- Compiler level support for embedding security/trust policy monitori=
ng.
|
3
|
- Traditional trust
- Static (w.r.t. program, potentially dynamic w.r.t. information)
- Transaction level
- Program level trust
|
4
|
- TCPA (TCG) Trusted Platform Module
- Crypto co-processor (RSA -512, 768, 1024, 2048 bits; SHA-1; HMAC)<=
/li>
- Components for asymmetric key generation, RNG, IO.
- TPM may use symmetric encryption internally.
- May implement other asymmetric components such as DSA or elliptic
curve.
- Endorsement keys/Attestation keys
|
5
|
- TPM allows for a trust layer in a PDA, PC, Cell Phone.
- e.g. Integrity of the boot-up process.
- Allows for protection of intellectual property (keys, other data,
programs).
|
6
|
|
7
|
- Devdas et al use VLSI process variations to generate a signature of=
each
hardware component.
- Develop a trust engine that composes system level trust?
- Trusted Circuits?
|
8
|
- The underlying thesis is that control flow integrity of a program i=
s a
good indicator of its trustworthiness.
- Our hypothesis is that any program behavior compromise whether thro=
ugh
data contamination or control contamination eventually is visible as
control flow anomaly.
|
9
|
- We associate a dynamite trust level, a value in the range [0,1] wit=
h a
subset of monitored entities in a program, which could be data
structures or control flow edges.
- At runtime, the trust value will change according to embedded check=
s in
the control flow.
- Trust here is an estimation of the likelihood of not breaching a gi=
ven
trust policy.
|
10
|
- McCluskey et al. proposed to use control flow signatures for fault
tolerance in a processor.
- The signature model contains:
- Each basic block i assigned a unique ID
- Invariant: global register GR contains ID of the current block at =
exit.
- Difference value for incoming edge (j,i) where j is the parent nod=
e for
i,
- Check for the consistency at i.
|
11
|
- Suppose control flow travels through (a,b). At block a, we have
- At block b, we need to check:
|
12
|
- The integrity of any subset of control flow edges can be dynamically
monitored.
- Which ones should be monitored? How to specify these sets (ones tha=
t are
monitorable)?
- Schnieder: security automata; Ligatti et al: Edit automata.
|
13
|
|
14
|
- A predefined set of monitored program events form ∑: each mal=
loc
call, access to the private key, buffer overflow – control fl=
ow
edge after the procedure call return.
- What kind of finite sequences specify a safety property?
- Security and edit automaton.
|
15
|
- An automaton is defined by the quintuple
- where
- is a finite set of states,
- is a finite set of symbols called the input alphabet,
- is the transition function,
- is the initial state,
- is a finite set of final states.
|
16
|
- A CFC automata is a security automaton which satisfies:
|
17
|
- Build a control flow checking automaton for a simple program:
|
18
|
|
19
|
- The CFC DFA is defined by
- where:
- Notice that en is the event generated by control flow entering a new
basic block.
|
20
|
- The input to our algorithm would be a CFC DFA and a program Prog th=
at
needs to obey the security automaton. The output of our algorithm i=
s a
program Prog' with CFC DFA embedded into source code.
- We assume:
- P: The set of program states
- Q: The set of automaton states
- S: The set of code insertion spots in the program
|
21
|
|
22
|
|
23
|
|
24
|
|
25
|
- Electronic commerce example (F. Bession et al., "Model checking
security properties of control flow graphs")
- The security automaton ensures that either there are no writes or a=
ll
the codes leading to write have Debit permission.
- Ewrite stands for the action of write.
- Pdebit stands for the permission to debit.
|
26
|
|
27
|
|
28
|
- F. Schneider, “Enforceable security policies”
- The following security automaton specifies that there can be no send
action after a file read action has been performed.
|
29
|
|
30
|
|
31
|
|
32
|
- We view trust with respect to a specified security policy.
- If a security policy is violated, trust w.r.t. that attribute is
lowered.
- Trust policy just an enhancement of security policy accounting for
updates of the trust value.
|
33
|
- Trust automaton:
- t is the trust update function: t(q,a) =3D val
- Could be a multi-dimensional update.
- When trust is lowered below a certain threshold, an exception could=
be
raised.
- Exception could call an appropriate service such as intrusion detec=
tion
system or trust authentication service.
|
34
|
- We have compiled and run two of the SPEC2000 benchmarks gzip and mc=
f to
evaluate both static and dynamic system overhead.
|
35
|
- Static system overhead
- Dynamic system overhead
|
36
|
- The performance overhead will be significantly reduced if the
architecture manages the trust attributes.
- Associate extra attributes with branch instructions:
- BEQ R1, target, BBID, D
- Being implemented in SimpleScalar.
|
37
|
|
38
|
- We proposed a control flow integrity based trust model.
- program's self assessment of trust.
- compiler driven approach.
- performance overhead.
- Trust engine based architecture for higher efficiency.
|