-
Notifications
You must be signed in to change notification settings - Fork 0
meetingNotes
Perry Alexander edited this page Aug 20, 2015
·
47 revisions
- Demo status
- Reschedule meetings
- Basecamp status
- Big picture concepts
- Adam, Prasad, Jason, Justin, Paul, Andy
- Where do protocols come from? 2. What properties should protocols have? 3. How do we know that protocols run properly? 4. How do we appraise protocol results? 5. Coordination
- Why do we trust anything? 7. What are our Roots of Trust? 8. How do we chain trust? 9. meta-evidence 10. strong identity 11. meta-measurement
- What are complex, multi-realm attestations? 13. multi-party 14. multi-realm 15. complex measurements
- demo status
- difficulty keeping the attestation manager communicating with the measurer.
- trying to keep comm alive between invocations. Why is this?
- state in the measurer must be maintained between sessions, thus we can't kill everything and restart
- communication port should stay open as a part of the M&A state
- right now we can do one attestation and need to restart
- Demo status
- General status
- Ed, Paul, Mark, Adam, Prasad, Jason, Me
- demo is broken, but close
- general broken-ness
- New demo
- sounds really good
- discovers buffer overflow
- can see what's happening rather than background failure
- property identified for measurement
- New demo requirements:
- need interaction with new
- Comm infrastructure is still coming
- end of this week in the best case
- Status
- Software engineering issues
- Perry, Ed, Adam, Paul, Jason, Justin
- Working on repos
- Cabal files for individual components
- Need to build demo 4 to confirm build system
- Shooting for finishing reconfig by end of week
- Thinking about automated testing
- Unit tests, not systems tests
- No restrictions on tool
- Status update
- Software engineering issues
- What "done" means
- Andy, Ed, Adam, Paul, Prasad, Jason, Justin, Perry
- JASON RPC
- Send JSON RPC to call eval
- Receive JSON structures with evidence
- Firewall semantically between implementation of measurement and the properties of measurement
- Software engineering issues
- Structuring repos
- Branches and tags
- Coding standard and structure
- Testing
- What "done" means
[x] Status update [x] Modeling update [x] Attestation and appraisal update [x] Measurement update [x] Status of Measurer integration
- Justin, Adam, Prasad, Jason, Perry, Andy, Paul
- Working through the coq tutorial and at the Imp section
- Pay attention to specification of meaning
- Looking at monad specification
- Successfully test http channel that is an instance of channel class in Haskell
- First instance of communication channel
- Integrate with Justin's work
- Working on ROP detection
- Can find a contrived ROP example
- Looking at more complex structures
- Working on integration of measurement with attestation
- Should support JSON RPC is likely, but up in the air
- Use one method or many methods
- Why use JSON RPC if only one command?
- Meta-commands, command sequencing
- Andy needs to understand the measurement language
- API is on the wiki
- Working on JSON RPC in Haskell
- JSON RPC in Haskell is an instance of remote
- With some caveats
[x] Status update [x] Measurer demonstration
- Ed, Adam, Paul, Prasad, Justin, Mark, Jason , Perry
- Jason showed the Measurer actually doing its tricks
- Set a hook
- Grabbed the hooked value
- Provides infrastructure and not appraisal code
- Still need to understand target values
[x] Status update [x] Bundling evidence
- Perry, Adam, Prasad, Ed, Mark, Jason, Justin
- Measurer API is coming along. Obviously nothing new since last Friday when we met.
- Interaction between attestation manager and Measurer might be a pure remote monad.
- RPC is weak remote monad and we want strong remote monad
- Strong bundles commands
- Weak does not bundle
- Working on unifying communication mechanisms
- Channel is a class with send and receive
- Looks like a monad
- Abstraction over channel properties
- Last of channel types that can be tried
- Lots of discussion or the nature of a protocol
- Need to look at ISAKMP and IKE
- Master/slave is too restrictive for negotiation
- Master/slave may very well be sufficient for atteststion
- Looking at structure of state and reader monads
[x] Summer assignments [x] DJ shift
- Ed, Paul, Adam, Prasad, Jason, Perry
[x] Debrief Summer School [x] Go/no-go Cluster teardown [x] Go/No-go TGC [x] Language and Measurement Meeting Agendas [x] Discuss Keck proposal [x] Discuss SaTC [x] Discuss AFOSR - ArmoredSoftware, Picture on page "BAA 2015"
- Perry, Andy, Adam, Prasad, Jason
- Long discussion about communications between measure and attestation manager
- Discussed topics for meetings later in the week
- No-go on TGC this year. Really need to focus on this for next year
- Summer school was a success
[x] Summer agenda [x] Platform issues [x] Remote monadic verification
- Andy, Prasad, Ed, Justin, Jason
- No one is using the Leon cluster
- Andy is looking at a session monad
- Remote with arbitrary depth
- Session monad over time generates a sequence of session type
- Questions beget questions - request to run results in a request to run
- Need to get this off the board after the meeting
- We are not using JSON RPC standard
- Andy and Justin are working on a prototype for this
- Can get this in place to allow a standard interface for measures
- Friday meeting defining where we are with measurement
[ ] Tear down old cluster [ ] Initiate protocol monad directory and start paper [ ] Set agenda for Friday (see above) [ ] Set agenda for Thursday (see above) [ ] JSON RPC [ ] Gatekeeper attestation protocol
- HCSS Debrief
- Summer planning
- Papers to target
- Me
- Discussed HCSS
- Discussed formalizing the protocol monad
- Defining the receiver
- Including session types - valid sequences
- Evidence protocol runs correctly on the remote agent
- Getting something ready for download
[ ] Decide on meeting times [ ] Find Hilo paper
- Prasad, Adam, Paul, Justin, Jason
- demo status
- discuss measurement architecture
- Paul, Justin, Prasad, Andy, Mark, Jason, Adam
- Demo status
- protocol monad discussion
- measurement discussion
- Demo is not quite ready
- Thursday demo
- looks good from what we see in the lab
- will need VPN for HCSS
- Protocol monad development
- structure research around this
- publish in ICFP
- session types
- - find session types paper. Uses indexed types that allow the type of the state to change during execution. Are protocols instances of a session? A state machine of types.
- Ed, Justin, Adam, Paul, Mark
- monad laws
- discussed the state monad laws as a model for protocol monad laws
- reviewed the remote monad laws
- they assume the remote is a slave that only does what it is told
- possible a good model for attestation, but not negotiation
- verifying the laws might give us evidence of ASP execution order and soundness
- develop laws for our monads that will lend themselves to efficient verification
The send monad laws as stated in the paper are currently:
send t $ return a == return a
send t M >>= (send t) . k = send (M >>= k)
In my notes I have made the c subscript explicit as the paramter t.
The first law states that asking t to return a is equivalent to not sending the request at all. No controversy here.
The second law states that asking t to perform M, then asking t to perform k in the context of the result of M is equivaent to asking t to perform M and k in sequence. This is subtle. Performing M and returning, then performing k with the result of performing M as a second request is the same as asking to perform M and k in sequence without returning.
The implications of the second law are important for optimization. Instead of sending one command per message, one can send a command sequence in one message. However, this assumes that t is a slave that takes no action it is not instructed to take. Our attesters and appraisers do not always behave this way.
Executing attestation protocols come close to the remote monad's second law. ASPs are often slaves to attestation protocol execution. More interestingly, if we can refine the remote monad laws to capture ordering they will prove useful for specifying, if not verifying protocol execution as required for appraisal. Think about proof carrying code as an example.
Executing negotiation protocols are different as the two actors are peers in the negotiation. They will do work between interactions. Thus, the second law will be impossible to verify unless the conditional results of the action can be captured. This will be difficult due to state information in the monad.
- Right now protocol monads are reader monads. This is good, but we did not discuss why.
- Discussed the state monad laws and whether they are sufficient to derive the state monad. Decided that they are not. They are laws that a state monad must obey to be treated like a state monad. This goes against the idea of deriving a monad from its laws.
- Prasad, Nilisha, Bharath
- status
- plans moving forward
- VMI allows VM introspection from outside
- more useful for ArmoredSoftware than ACHILLES
- Volatility
- looks at an image of RAM
- does similar things
- Steve's notes
- gathering information that is more application specific going forward
- will look at what we can do in the short term
- using database for data coming out of tools
- Prasad, Perry, Adventium
- Debrief PI meeting
- we did well in the engagement (])
- discussion of safety and likeness
- not using the terms in a standard way
- seems they are show horning something into this
- SystemVerilog assertions discussion
- will give us router firmware if we want it
- next engagement is around gumstix
- can do more if we want
- will low us to consider multiple processors
- don't have to do this
- they will provide things to discover
- Status
- Debrief Demo
- Planning
- Andy, Prasad, Jason, Adam, Paul, Ed
- Status updates
- Demo planning
- General planning
What we intend to do over the next three weeks:
- 1/6 - Demo Planning
- 1/13 - Demo Dry Run
- 1/20 - Plan the semester
- 8:30am EST, January 15
- Sterling Drive facility
- Execute demo remotely on KU systems
- Introduction and Project Goals
- Big picture picture
- Design refinements
- Prototype demonstration and discussion
- Refine big picture to current demo
- Measurement
- Protocol execution
- Appraisal
- Communication
- Stepwise demonstration
- Short term goals and milestones
- What will we target this year?
- What will our milestones be?
- Questions and guidance
- What problems are interesting to the sponsor?
- What would make a nice "splash"?
- What should we be watching and integrating with
- Make sponsor look good
- Educate community on program goals
- Educate sponsor and community on current status
- Learn more about potential demonstrations
- Who is responsible for materials?
- Who is going?
- Travel planning
- strand space discussion
- status
- Andy, Prasad, Adam, Paul, Justin, Jason
- Planning for sponsor demo
- Continued SPI discussions
- Add BAN logic and Strand Space to semantic models
- sponsor demo dates
- next Friday if no travel
- January if possible
- Perry will go alone if needed
- BAN logic and strand spaces
- strand space papers next
- BAN logic after that that
- the whole gang
- Continued SPI calculus discussion
- Status
- The entire protocol is now running with the attestation manager talking to the measurer
- Demo 4 is complete
- Continuing discussions of SPI
- Need to explore the asymmetric extensions proposed in the paper
- Status reports
- SPI Calculus reading
- planning
- ArmoredSoftware team
- status reports
- planning
- Leon still working on long-term fix for version ingredients
- making progress
- VMs are now starting
- no communication with VMs
- fedora 20 and Xen 4.3.3 with xsm
- Jason working on a link that will get comm with vchan going
- not too long - next week
- setting up detectable bad state
- Adam appraiser detecting bad responses
- looping to generate all possible outcomes
- vchan is causing problems
- issues with vchan
- Paul fixing sandbox issues related to vchan
- using http to communicate
- okay as we need this mechanism anyway for inter-Xen communication
- Justin reading FRP
- Status updates
- Design tasks
- communications infrastructure
- armored CA
- name server
- communication execution
- remote execution / reactive execution
- measurement
- measurers and evidence
- persistent measurement
- measurement & evidence language
- trust infrastructure
- roots of trust
- measured boot
- vtpm/TPM
- correctnesss
- attestation infrastructure
- language of trust protocols
- protocol execution
- protocol appraisal
- correctness
- Perry, Andy, Prasad, Justin, Paul, Adam, Jason, Leon
- Status updates
- Year 1 demonstration planning
- Adam, Justin, Paul, Jason, Prasad, Andy, Perry
- Weekly status update - @done
- Trip report - @done
- Trusted boot discussion - @done
- measurement
- Jason is working on his thesis
- hung up on fedora 7 install
- this is becoming critical and need progress after thesis defense
- attestation
- Adam is reading
- infrastructure
- Justin is working through
TBOOT - Asked him to start looking at a
TBOOTinspired solution for booting ArmoredSoftware nodes
- Justin is working through
- vTPM
- Paul is reading the IBM paper on vTPMs
- Adam, Justin, Jason, Paul, Andy, Prasad, Ed
- Trust presentation - @done
- Status updates - @done
- Next steps - @done
- Trusting the platform - @done
- Armor NOC - @done
- Wrapping up Year 1 - @done
- New business - @done
- Went through remaining slides in the trust presentation
- TPM integration
- Berlios is running
- Most commands we need integrated in Haskell
- vTPM state storage is an issue - we reinitialize the vTPM on each run
- Talking to the HW TPM as well
- JSON structures are in place
- Moving to RedHat
- Talked with Leon and there are a few installer issues
- Leon is going 1/2 time and will work from home
- Adam, Justin, Andy, Prasad, Jason
- Weekly status - @done
- OpenStack updates - @done
- Demo 3 is about adding trust - @done
- Certificate Authority
- Core hours on the wiki or Googld calendars - @done
- Roots of trust - things we trust implicitly
- Measurement - obtaining information from systems (Processor)
- Storage - storing information (TPM)
- Reporting - sending information to other agents (TPM)
- Chaining trust from roots
- Directly observing or indirectly observing through a trusted third party
- Measurement
- Jason is working on his thesis
- Still not to fedora
- looking at attack on java app
- Infrastructure
-
vchanintegrated with cloud Haskell -
expectapp to get info about starting apps - plan for trusted boot
-
- Attestation
- TPM emulator running
- Haskell interface is running
- Need additional commands for this demo
- Schedule meeting for fall semester - @done
- Set up blackboard for schedule and meetings - @done
- Justin should be moving to,trusted boot - @done
- Let Galois know about TPM interface - @entered
- Schedule a trusted computing seminar - @done
- Weekly Status - @done
- OpenStack contacts - @done
- Demo 3
- Roots of Trust
- Year One Demo
- Appointments and Enrollment - @done
- Core hours in Nichols - @done
- Keeping the wiki up-to-date - @done
- Appointments are complete for the fall and spring
- Establishing contacts within the OpenStack community
- We have an opportunity to make significant contributions
- KU could own OpenStack security and trust if we buckle down
- Demo 3 is about establishing and using roots of trust
- Including the (v)TPM as a root of trust
- Establishing trust in the application
- Establishing trust in the infrastructure
- Late launch of the VM
- Please add to and maintain the wiki
- Conferences and references are key right now
- Add BibTeX to references if possible
- TPM Haskell interface is compiling #on compute node
- shell starts, but is not talking with the TPM
- emulator is a work in progress
- JSON interface between VMs
- communicating among all VMs
- standard structure for wrapped data {>>note that this is not TPM wrapped<<}
- JSON over
vchanfrom attester to measurer and from appraiser to attester - string management among languages
- network protocol execution has a place in this work
- Send TPM tutorial to Adam and Paul - @done
- Weekly status
- Demo 2
- stuck with hotspot not running on CentOS with
vchan - still need Fedora as the problem is with CentOS
- waiting for scripts that automatically start VMs
- stuck with hotspot not running on CentOS with
- We need to run with Fedora or RedHat
- Xen and OpenStack are issues
- really a python library issue
- JSON is communicating between measurer and attestation manager
- should do the same thing between appraiser and measurer
- different language support for JSON
- Protocol execution as monadic execution is working fine
- looking at tpm integration
- communication issues
-
vchanfor process comm -
vchanfor VM comm - something else for cloud comm
-
- Move completely to Fedora - @entered
- Move from Haskell to JSON from appraiser to attestation
- Look for other languages talking with JSON
- Start thinking about the ArmoredSoftware name server
- Ed, Paul, Andy, Leon, Perry, Justin, Prasad, Jason
- Weekly status - @done
- Demo 2 - @done
- XSM boot
- racing to see who can get XSM up with debug turned on
- debug is the issue at this point
- debug needed for HaLVM
- moving to Fedora from CentOS
- only issue is XAPI and thus OpenStack
- alternatives to OpenStack
- XAPI is critical for OpenStack
- OpenStack and XAPI
- working on contacts
- Citrix seems to be the lynchpin
- Demo 2
- close on the protocol side do things
- using IO monad rather than STM
- STM shares a variable
- we communicate with
vchan
- define measurements between attestation and appraisal
- communication hierarchy
- STM between OS processes in the same Haskell instances
-
vchanbetween different Xen VMs and between Haskell instances - Cloud Haskell for inter Xen communication
- comm problems with
vchanstill exist- see what happens when we move to Xen 4.3
- could move to 4.4
- measurement
- 32 bit to 64 bit hotspot
- infrastructure heartache
- data format between measurer and attestation
- attestation
- close to implementation
- discussed enveloping of evidence using hashes
- discussed the role of keys and hashes
- appraisal
- define measurements between attestation and appraisal - @entered
- provide a mechanism to compromise the measured VM - @entered
- define a data format for exchange of measurement data - @done
- Perry, Prasad, Evan, Paul, Adam, Ed, Jason
- Weekly status
- Demo 2
- Literature search for protocol design
- no one has done this before
- thinking about sequencing
- expressions, control, communication, data
- HotSpot running on CentOS
- Not much pain
- looking at Paulson paper on protocol verification
- looking at references
- looking protocols from the paper
- Niedham-Schroder
- Communication issues
- Push up paper Konrad discussed - @done
- Strand space work from Joshua - @entered
- Perry, Leon, Prasad, Justin, Jason, Paul, Adam
- Internal presentation of Demo 1 - @done
- Discussion of Demo 2 - @done
- Weekly status updates - @done
- Demo 1 notes
- separate VM communication is working fine
- single VM
vchancommunication is crashing still - two terminals on compute 5
- two VMs with fixed IDs
- start attestation with fixed domain id for appraiser
- start appraiser with fixed domain is for attestation
- domain IDs used for communication
- demo 1 is in the books
- issues
- static IPs are still a problem
- single VM
vchanis still failing - data is still going over the control network rather than the data network
- sharing keys is still a pain, but we know that
- key management is largely a mess
- demo 2
- no changes from initial plan for now
- major goals
- communication with measurer
- more interesting measurements
- protocol execution
- composite evidence
- inter-Xen communication (cloud)
- first steps toward verification
- status updates
- None
- None
- Perry, Andy, Prasad, Evan, Paul, Adam, Jason
- Architecture discussion - @done
- Crypto mechanism - @done
- Demo 1 Progress - @done
- Demo 2 Progress - @done
- Literature studies - @done
- Odds and Ends - @done
- Rockwell Collins Debrief - @done
- Monitors, keyboards, compute nodes - @done
- Architecture discussion
- Communication mechanisms
- VM infrastructure
- Cloud infrastructure
- Demo 1
- Attestation and appraisal are separate VMs
- crypto functionality is working, but not necessarily what we want long term
- Galois has crypto for HaLVM
- Caution for download
- no typed channel yet, but should get there
- can do by agreement
- sign with type
- nifty Haskell package out of this
- Verification infrastructure
- thinking about comm verification
- thinking about structure of verification subsystem
- proof for serialization
- Demo 2
- Updates in web and architecture paper
- mainly figures
- Order compute node for cluster
- Order 2 monitors for student desks
- Consider purchasing several Raspberry PIs
- target IFL for paper on typed communication channel
- Think about HTTP as a measurement target
- Think about the verification aspects of demo 1
- Look at verification of the communications infrastructure
- Look at cryptographic protocol verification {>>This should be trivial, but needs to be done<<}
- Implement Quickcheck across software infrastructure
- Jason, Justin, Paul, Adam
- Communication mechanisms - @done
- Demo 1 status - @done
- Repo issues - @done
- wiki and planning issues - @done
- Still working on issues related to tracking
- will try the wiki now
- other stuff is not well integrated
- CentOS is painful, but there may be no advantage to moving
- one compute node at fedora to mimic Galois
- Galois is using a custom Xen kernel
- communication infrastructure
- looking at cloud Haskell for communication among Xen installations
- looking at
vchanand HaLVM for IVC - really want one API in the protocol language
- Protocol executions going
- using parallel Haskell before we have comm
- working on protocol execution
- Using static analysis to predict what patterns ahold not appear
- a dynamic state that static analysis does not predict is a problem
- already do call graph and control flow
- Dig up notes on repo branching - @done
- See what crypto libraries Galois uses - @done
- New People - @done
- Discussion of demonstrations - @done
- Task status - @done
- Look at GitHub issues tracking system - @done
- Assign background readings - @done
- XenStore has a pragmatic limitation on message size
- vchan in Haskell is coming along
- Issues currently with control characters in communication
- Communication is typed - the things that are communicated have Haskell types
- Found a blog post on protocols in Haskell
- Need to check out how it fits with
vchan - Need to integrate approach with our mechanisms
- Need to check out how it fits with
- Need standard crypto libraries for Haskell
- RSA standard and nonce creation
- Build quote creation software
- Getting
vchanand STM library living together - @entered - Put blog on communication on website - @entered
- Find standard crypto library - @done
- Write quote creation software working outward to protocol - @done
- Communication between measurement and infrastructure - @done
- Readings to GitHub - @done
- Tasks and schedule to GitHub - @done
- New People
- Introduce demonstrations
- Discuss todo lists and logs
- Assign background readings
- Using github issues for assignments
- Haskell is opening vchan
- starting communication in Haskell
- vchan issues
- isn't designed to compile in MiniOS
- HaLVM is MiniOS based
- vchan in HalVM must be done
- Look at OpenAttestation - @done
- Look at IBM Integrity Measurement Architecture - @done
- Perry, Prasad, Andy, Leon, Jason, Justin, Evan
- Summary reports
- Go through attack plan
- Justin and Leon have vchan working
- C right now
- Will move into Haskell
- Looking at XSM integration
- Not using Cloud Haskell
- Will roll our own from the cloud Haskell infrastructure
- Publish this in IFL this fall
- HaLVM is being investigated
- Evan said we're close
- Evan said we're not close after that - Still working
- Connection to mutant cloud haskell will be awesome
- Research outline
- Lots of discussion about what we're doing and when
- Capture on the outline on the wiki along with comments
- See Work Plan for outcomes from this
- Push the outline onto the wiki - @done
- Set up a publications repo - @done
- Perry, Prasad, Andy, Leon
- Debrief the kickoff and HCSS
- Will add notes from HCSS, the kickoff and post-kickoff to another entry on the wiki
- None
- Andy Gill, Pete Loscocco, Machon Gregory, Daniel de Graff, Perry Alexander
- Discuss kickoff meeting
- Discuss Pete's design description
- catch up on TRP activities
- User space measurement is harder than OS measurement
- every measurer is different
- parts of executable May swap out
- memory structures can change from version to version
- Can the compiler inform measurement
- We believe so
- This was our NSF proposal
- really no choice if we want to do it
- User space measurement of environment is limited
- By what the measurer can "see"
- looking down is quite different than looking up
- measurer still needs a root-of-trust or safe place to work from
- How "lightweight" can this actually be?
- Pete is skeptical of what can be removed
- I believe reduced generality of the infrastructure will result in lighter applications
- Interesting discussions of not having roots of trust
- further confirmation that software roots of trust are weak
- Next generation PIONEER work is just as weak
- How much trp infrastructure can we use?
- SDP is too brittle and old
- Galois components are not integrated
- HaLVM has promise for us
- we'll use what we can and look around
- Daniel has pushed quite a bit into OpenStack
- we need to coordinate with Daniel
- vTPM is integrated
- Coordinate work with Daniel - @entered
- look for infrastructure that implements domain builder and vTPM then
dom0- @entered
- University of Kansas: Dr. Perry Alexander (Presenter) and Dr. Andy Gill
- Southern Cross Engineering: Ed Bishop
- Government: Tim Thimmesch, Frank Taylor, Alice Pelkey, Jim Rauscher, Orville Stockland, Anita Woodley, Marchon Gregory, Pete Loscocco
- Describe the ArmoredSoftware program
- Gather information from the customer
Dr. Alexander presented the slides provided via soft copy to Mr. Thimmesch on May 9, 2014.
- Pete Loscocco explained that in place of the TRP acronym, we should use SVP (Supervisor Virtual Platform).
- Orville Stockland suggested that OPEN STACK legacy includes USC, CMU, Aerospace, Hewlett Packard and others. Also McAfee and Black Duck Software are notable validators
- Mr. Stockland asked what the license cost was projected to be for Armored SW and Perry stated it was planed to be open-source.
- It was suggested that the Armored SW team talk with USC-SI’s Dr. Steve Krago (spelling?) as well as Dr. Joe Banister (spelling?) at Aerospace.
- It was also suggested the we connect with Dr. Alex Slay at Hopkins to explore if we may leverage the "Big Sky" model.
- It was suggested the we copyright "Armored SW"
- It was suggested the Perry access Open Attestation.com to explore how we may leverage what is available herein.
- Suggested that we have an unclass teleconference as introduction of Armored SW team with CMU and Aerospace.
- The question was asked; what Hardware does Armored SW require
- Answer nothing special - Intel based processors with TPM
- There was question as to whether Armored SW would attest FPGA code.
- Yes if measurers can be written for the FPGA source it would require no additional infrastructure
- The comment was made by the Government that Armored SW was good fundamental work.
- It was recommended that we review the IBM-IMA (Integrity Measurement Architecture.
- IMA is utilized in LINUX.
- Anita recommended that Armored SW collaborate with Open Stack Group
- It would be a big plus for DoD to get this.
- Look at Daniel De Graff's involvement
- Spoke with Daniel after the kickoff and he is interested
- Need to get formal approval to do this
- Pete suggested that we take the approach to ask "Where is trust required?"
- How can that be requested in a generic way?
- Trust as a service
- SGX (Intel) is a potential execution environment
- This is a real emerging technology for trusted execution
- Encrypted memory only clear in cache
- Is this a technology that will enable us to better support our assumptions?
- This is a real emerging technology for trusted execution
- vTPM Light and Lightweight infrastructure
- it was suggest that we take care to not make it too light that it may limit trustworthiness.
- Demo Suggestions:
- Protection of Grades
- Segregation of HR data
- Orville offered to provide contact information for Open Stack Consortium members - @entered
- Talk with USC-SI’s Dr. Steve Krago (spelling?) - @entered
- Talk with Dr. Joe Banister (spelling?) at Aerospace - @entered
- Talk with Dr. Alex Slay at Hopkins to explore if we may leverage the "Big Sky" model - @entered.
- Copyright "Armored SW" - @done
- look at OpenAttestation.com - @entered
- Review the IBM-IMA (Integrity Measurement Architecture) used in Linux - @done
- Recommended that Armored SW collaborate with OpenStack Group - @entered
- Look at Daniel De Graff's involvement - @done
- Look at SGX from Intel - @entered
- Andy, Perry, Prasad, Justin, Jason
- HCSS planning
- weekly review
- Poster Requirements
- what are you doing?
- what have you done?
- what are you going to be able do?
- why are you doing it?
- Poster outline for Andy and Prasad - @done
- Forward protocol to Andy and Justin the attestation protocol - @done
- Send Prasad HCSS booking info - @done
- List of HCSS people to talk with - @done
- Set meeting with Rockwell - @done
- Andy, Prasad, Justin, Jason, Perry
- Weekly review
- Learning trusted computing basics
- Example in repo of VMs communicating
- Not done, but running
- using Cloud Haskell
- uses IP addresses
- does not use IVC
- HCSS is accepted - we will be presenting
- Measurement
- Signal handler is done - detecting an external signal
- monitor thread is working
- Provides simple things now setting stage for bigger things
- Set up issue tracking in GitHub - @done
- Plan and organize HCSS - @done
- Figure out IVC using domain IDs as the comm mechanism - @done
- Look at XSM and see if this can be implemented in Haskell - @entered
- Andy, Prasad, Jason, Perry
- Weekly meeting
- Andy is exploring cloud Haskell
- Messaging infrastructure - Lightweight
- typed message
- independent of messaging infrastructure
- CCI is the middleware - Common Communication Interface - government standard
- Haskell model built on the cloud Haskell model
- HotSpot is compiled
- Starting to think about modifications and monitoring
- Document protocols for demo and prototyping - @done
- HCSS submission - @done
- Perry, Andy, Prasad, Justin
- Discuss notes from telecon with Ed
- status update
- Discussed the several demonstration targets talked about with Ed
- Moving computations into secure clouds
- mutual attestation among agents working on the same data
- mutual attestation among agents working at multiple security levels
- Andy work on end-to-end demonstration in Haskell model
- Independent from implementation
- simple flow for initial demonstration
- Perry, Ed
- Catchup
- Ed is looking at potential applications
- Working with internal big-data providers
- Thoughts on applications
- Flip the big data idea from moving processes from Baltimore to date to moving processes from outside to Baltimore
- Trust in multiple processes access the same data
- Mututal attestation among users
- Multiple security levels by multiple users
- Discovering bad emergent properties
- Accessing secure VMs running on a common infrastructure
- Kind of lame, but on target
- Perry, Leon, Andy, Prasad, Justin
- Weekly status meeting
- production cluster is up
- Xen is installed
- no OpenStack for the time being
- move to 4.3 likely to be our responsibility
- stub domain is performing measurement
- Talking to hypervisor
- vchan sets up shared pages and uses XSM
- Discussed access control and how XSM uses it
- we will need to implement access control, but will not make contributions here
- domain specific language for trust will need to account for this
- Discussed MiniOS and what stub domains do
- discussed using Haskell in VMs
- Runtime for Haskell is big
- need a lightweight Haskell platform
- getting started with monitoring in the JVM
- We decided this would be our first target - Looking a virtual execution is simpler
- will make queries of the running JVM to perform measurement
- task requesting measurements from running processing
- starting with system calls
- modifying the hotspot JVM
- Haskell model for the armor
- Using blogger to record work
- request response monad for interactions - just a transliteration
- moving up in abstraction to CCI - used by cloud Haskell
- Need to understand what our development targets are
- MiniOS for stub domains
- CirrOS for lightweight domains
- CentOS or Fedora 20 for full-blown domains
- what is the abstraction level of the measurement request?
- define the interface between protocol and low level calls
- need to understand what the next
- Andy, Prasad, Leon, Perry
- Andy suggested starting working on protocol definition by modeling the architecture
- Will block out the architecture
- Identify missing elements in the architecture document
- Abstract definition of data structures
- Define measurements
- Identify specific measurement targets
- genome client
- web services
- contact ed for concrete examples
- define measurements for those targets
- Identify specific measurement targets
- Contact Ed for concrete examples - @done
- Perry, Andy, Prasad
- Monthly inputs - All
- Hiring and Spending - All
- Demonstration definition - All
- Architecture modeling - All
- Meeting with sponsor - Perry
- To Do list review - All
- Hiring is going well
- Need to establish a lab culture
- Community first
- Andy suggests a meeting with students
- Scheduling of sponsor meeting is ongoing
- development infrastructure
- Hardware - 8 compute nodes on main cluster, 3 in Leon's cluster
- Software -
- Schedule initial technical meeting with students - @done
- Principles paper is required for meeting - @done
- Perry, Andy, Prasad, Leon, Justin, Jason
- To do list review - All
- Cloud setup - Leon
- Capability briefing - Perry
- Architecture modeling - Andy
- Demonstration definition - Perry
- Meeting with sponsor - Perry
- Hiring - All
- Andy found something called Cloud Haskell
- Erlang in Haskell - lightweight threads in Haskell
- Useful for communications in Haskell
- how does this integrate with IVC?
- Hiring
- Offers out
- SELF
- Capability briefing
- Ed and perry are working in this
- standard presentation for all to carry