-
Notifications
You must be signed in to change notification settings - Fork 0
measurementNotes
Perry Alexander edited this page Aug 20, 2015
·
1 revision
- Status
- Next steps
- discussed Measurer capabilities
- what's next?
- conditional measurement
- control and procedural abstraction in the attestation language or attestation protocol?
- control must be in language
- procedural abstraction maybe not
- macro capabilities?
- what directions for static analysis?
- find frameworks for static analysis
- what kind of static Analysis?
- invariant checking (not that great)
- invariants associated with specific attacks
- remember Aaron's guidance
- Status
- Automated testing
- Application measurement
- ASP integration
- Tests are now running automatically
- Only preliminary results so far
- Need to run more tests before reaching conclusions
- Deterministic testing is difficult
- Next steps from Prasad
- Determining what measurements are needed
- Improving the measurements
- Next steps from me are consistent
-
Integrate current example with demo - Demo 5
-
Hand picking measurements for a specific example
-
- Status
- Unit tests are running manually
- Looking at overhead of measurement
- Next step will be interpretation of measures
- Look at full application measurement quite soon
- Discussed publication opportunities
- Status
- Integration of measurer with ASPs
- JSON interface with attestation infrastructure is almost there
- Single string passed to eval using JSON RPC
- Return data also formatted using JSON structure
- Looking at catching ROP attack
- Measurement triggers on system calls
- Is this too predictable? Can an adversary use this knowledge to avoid measurement
- Looking at publication towards the end of summer
- Status
- Interface with attestation manager
- Working in ROP example
- Using special compiler to generate ROP payloads
- Demonstrate detection of ROP attack
- Working on the API to be more useful
Set-target
Send-me measure callstack
Send-me measure var "a"
Store 1 measure callstack
Hook delay 1000 0 '(store 1 (measure callstack))
Send-me load 1
Hook (Reach "main.c" 49) '…)
Kill 1
Quit
Need to document this language on the wiki.
- Backend is GDB right now
- Think about sql for the comm graph structure
- Status
- Call stack is implemented
* Immediate
- Set a timer and get back a measurement ID to retrieve later
- Repeating timer generates a trace
- Kill existing hooks or events
- Working on getting variables
- Other measurements
- Looking at more powerfully API, but waiting to learn more about that
- Communication graph generated statically
- New goal
- Generate golden call graph
- Gather measurements during attestation for communications
- Query the call graph during appraisal
- Examples
- SSH daemon communicating over a high port
- HTTP daemon exhilarating data
Asynchronous vs synchronous Measurement triggers and events Short lived vs long lived measurerers
Long discussion about measurement covering what I anticipated we would cover. There is confusion over what measurement does. I described it as an annual physical. Yes it is a one-time, one shot measurement, but it can tell you quite a bit about a person's health. Doctors have decided that it should occur annually based on a risk/reward scenario. Will more frequent physicals pay for themselves in more effective treatment? At some point the doctors said no and decided on once a year.
- Attestation makes it harder for the bad guys to do work
- It is not perfect
- It will not catch everything
- Decided that measurement operations never initiate contact with the attestation manager
- May be synchronous or asynchronous
- Never initiate attestation actions in the current model
- Measurement may not be on demand, but contact among the appraiser and measurer certainly is.
- Sticking with three kinds of measurement
- Single shot, on demand
- Trending over time
- Tripping based on system events
- Need to provide Jason with primitives to store protected data
- Protect integrity of measurements at rest
- Protect integrity of measurements during acquisitions
- Status dump
- Defining summer goals
- Two paths - different tools
- Monitoring - runtime profiling
- Detecting what is expected - static prediction
- Jason is building API
- Monitoring unit does not change
- Attester decides what to look for
- API provides common interface
- Using GDB for monitoring
- Still will need compiler help
- Process - right now temporarily stopping before measurement
- Attach to a process
- One-time measurement
- Trending over time
- Tripping based on events
- Static analysis tool does not exist currently
- App Characterizer
- Figuring out what to expect is still a hard problem
- Spectrum of capabilities
- Automatic characterization
- Semiautomatic with annotation
- Using DSEL to provide guidance
- Need to characterize what we can see
- What class of attacks can we detect with our API?
- What anomalies can we see?
- Status
- Static measurement
- Bharath's tools run as a boot service after boot completes
- Can look at things done during boot
- Looking at hierarchical hashing
- Hash the systems and the files together and separately
- Allows discovery of issues through searching the hierarchy
- Can make appraisal decisions based on that
- Target is gumstix
- Can we run on a traditional Linux distro?
- Bitbake is the major distinction here
- Will be Bharath's MS project