User-Controlled Dynamic Collaborations John Zic UK eScience Institute 8 July 2008

advertisement
User-Controlled Dynamic Collaborations
John Zic
Research Director, Networking Technologies Laboratory,
ICT Centre CSIRO
UK eScience Institute 8 July 2008
Background – who are we?
• Networking Technologies Laboratory: developing
systems that facilitate secure, trusted collaborations
between people
• Geographically dispersed areas, multi-person and multi-site.
• Secure, private and trusted interactions
• Low-latency, high speed network connectivity
• Six years of experience with the CeNTIE project and
engagement with our Focus Group members identified
needs:
•
•
•
•
Digital Media
Health
Enterprise
Regional
People working together
Highlights from NTL’s CeNTIE project
Secure transfer of medical
records using Trusted
Computing technologies
Braccetto -- a HxI
initiative between DSTO,
NICTA and CSIRO
Remote Immersive
Diagnostic and
Examination System
Multimedia annotation,
indexing and searching
Some questions
If we assume that
•
•
Networking is ubiquitous and bandwidth is not an issue
Storage is not a problem
then
•
What are the major issues and problems faced by your
organisations?
•
How can CSIRO, through the ICT Centre, make a difference to the
organisation and the way that they work?
These questions helped define the scope of the Enterprise
Systems Focus Group at first meeting in September 2005
•
Members: ATO, Australian Treasury, Westpac, CommBank
Response:
• It’s all about control of information and ease of deployment of
resources to collaborate
• across organisations
• within organisations (including departments)
Trusted Services Project
• Trust between collaborators is mobile and
portable to where ever they are connected
eContract
• Trust Extension Device (TED)
eContract
• User defined configuration of trusted
infrastructure for dynamic collaborations
•
•
•
•
Rapid automated deployment
Based on the use of an eContract specification
SOA based system design and implementation
First prototype demonstrated May 2007
• Implementation and testing using our the
experimental network
• Networking infrastructure -- Layer 2 and Layer
3 extranet services
• Storage infrastructure -- Distributed; Secure;
SAN; ….
eContract
The Dynamic Collaboration Service (DCS)
• Basis: we have assumed our systems will consist of a
hierarchy of Virtual Service Operators (VSO)
• Each VSO will be able to
• Offer distinct storage, connectivity and other “infrastructure”
type services
• Compose services from other VSOs and add in their own value
added features
• eContract defines required ensemble of resources
(services, software, people, infrastructure) in a
collaboration
• eContract is negotiated between partners ahead of
collaboration starting and infrastructure deployment
• An eContract provides simple, uniform way of configuring
resources for dynamic collaborations.
• eContract specifies policies, configuration and management
requirements
eContract life cycle
Contract
Terminated
Contract
•
•
•
•
Clause with policy
statments
Clause with
participants
Clause with resources
contributed
Clause with resources
required
•
•
•
•
Negotiation
Validation
Instantiation
Contract
Agreed
•
•
•
•
Clause with policy
statments
Clause with
participants
Clause with resources
contributed
Clause with resources
required
Contract
Instantiable
•
•
•
•
•
Clause with policy
statments
Clause with
participants
Clause with resources
contributed
Clause with resources
required
Termination
Contract
Active
•
•
•
•
Clause with policy
statments
Clause with
participants
Clause with resources
contributed
Clause with resources
required
Clause with policy
statments
Clause with
participants
Clause with resources
contributed
Clause with resources
required
Virtual Service Operator Architecture
(storage)
VSOs for Network Connectivity Service
Note:
The eContract Service and the VPN
Service can be operated either as
• separate business entities or
• two components in one
business entity
Current eContract Connectivity Service
1. Everyone can subscribe to the eContract
Service
2. Anyone can initialise an eContract to form
an extranet
3. The eContract is able to be:
a.
b.
c.
d.
Negotiated
Instantiated
Monitored
Terminated
and create and maintain an extranet
between the partners
Conclusion
• Future work:
• Integrating DCS into a collaborative platform
• provides the underlying services needed to ensure that
collaboration information is contained strictly
• Applications and interest for:
• Medical specialist case review
• Mining industry
• eContract
• Formal Semantics
• Continuation of protocol work
• Validation of protocols
• TED – seeking to commercialise and continue work at refining
the current implementation, integrating it into the eContract
system
Aim: to develop systems that facilitate secure, trusted
collaborations between people
Trust Extension Device Related Slides
Motivation and Inspiration
• Came from our earlier work in augmenting the user
controlled privacy eConsent work with TPM
technologies in 2005
• The work made us realise that there were large
problems of providing trust under real world conditions
• Cannot assume that the network and host to be
configured in any particular way or reliable!
• No secure hyperkernel
• No TPM or similar technology
• No supporting PKI or other security and authentication
infrastructures
• No security
• Further, users want a solution that
• Is mobile
• Allows them to perform trusted transactions anywhere, anytime,
without carrying around a “secured”/trusted laptop
The basic idea…
• Demonstrated the use of TPM based eConsent system
to Enterprise Focus Group members
• Technical representatives from two major banks, and two
major Australian government departments
• Their comment -- “Unmanageable” if deployed “in the
wild”
• Further discussions lead to idea of not attempting a
general solution but rather a tailored solution
• Device/system would be issued by a large, trusted
organisation such as a bank
• Complete control over entire operational environment
including TPM certs etc
• BUT needs to be cheap and small
TED v1.x Features
• Plugs into any PC with a USB port
• Read-only
• No need to reboot
• No need for special driver installation
• Control of environment by issuing enterprise
• Application OS keys and certs
• Mutual attestation between all three entities in the system
• client TED
• issuing enterprise server
• Privacy CA
• Secure (SSL-based) connections through host to
issuing enterprise and Privacy CA
TED v1.x Architecture
Trusted Operating
Environment
TPM
host
“Attacking Virtual Machines: A Threat Analysis of Virtual Machines”,
Tim Ward, CSIRO ICT Centre
Trust Extension Device Enterprise Architecture
Issuing Enterprise
Privacy Certifying Authority
Client’s TED
A Timeline of TED related work
Initial FG
Demo (Sept)
2004
Patient Centric
eConsent model
2005
VM attack
Australian
patent
filed (Sept)
2006
FG demo
(Feb)
2007
2008
eConsent
+ TPM
TED v1.0
TED v1.1
TED v1.2
“MediClient”
“banking”
“banking”
“email”
SW based
HW based
TED
TED
TED
“Gumstix”
eContract
Biometric
Final FG
Demos (May)
TED v1.x prototype: issues
• Certs and keys are “exposed” – software library + API
• Add TPM chip onto USB stick
• Entirely in App space & no root of trust
• VM used to execute the TED’s OS and applications
• Issues may be addressed by putting in CPU + TPM chip and OS into
USB stick
• Change of architecture for TED + enterprise
• Subject to common attacks:
• Key logging
• Screen capture
• Memory attacks
• Just as many countermeasures (on-going)
• Counter countermeasures
• Counter counter countermeasures
• Counter counter countermeasures
⊥
human behaviour -- send in the legal team Summary
Trust Extension Device prototype:
• Small, Portable
• current implementation on a USB memory stick
•
•
•
•
Targetted application and use, not general
TPM based implementation
No special installation required on host machine
Part of an integrated system
• Issuer
• Privacy Certifying Authority
• TED itself
• Flexible applications possible
• Banking application prototype
• Synchronous email prototype
• Entire system is under the control of the issuer
• Cannot be copied or modified
• Attested to be “as expected” before each transaction
Further Work
• Secure the TED v1.x prototype
• Crypto VM & trusted microkernel
• Utilise HW based TPM
• Analysis
• Trust & Security
• Performance
• Hardware based TED work
• Architectures re-done
• Enterprise
• Device
• Introduction of “out of band” authentication and transaction control
• Analysis
• Trust & Security
• Performance
• Answers to both these questions are important for
commercialisation and deployment success
Further further work
• Another future investigation: multiple applications from
different issuers
• TPM handled how?
• Virtualisation?
• Management of system, including
• Issuing?
• Updating?
• Revocation?
• Attestation protocols?
• Enterprise Architecture?
• e.g. banks need to agree but this may not be easy
• e.g. medical system needs to agree but this may not be easy
• e.g. brokering system – may be easier to get agreement
• Do we need to revisit the TED v1.x architecture? (suspect yes
but need to find out!)
CSIRO ICT Centre
John Zic
Research Director, Networking Technolgies Laboratory
Phone: +61 2 9372 4122
Email: john.zic@csiro.au
Web: www.ict.csiro.au
Thank you
Download