1. Encrypted Data Store, Hydra & Delegation Interface
Ricardo Rocha
On behalf of the JRA1 Data Management team
JRA1 All Hands Meeting, CERN
23 March 2006

2. Outline Encrypted Data Storage in MDM Hydra KeyStore Delegation 1.1
JRA1 All Hands Meeting, CERN

3. Encrypted Data Storage
System developed as part of the Medical Data Manager
Requirements
Patient privacy
Needs fine access control (ACLs on all data and metadata)
Needs metadata contention (metadata databases administrated by accredited staff)
Data protection
Needs data encryption (even grid sites administrators are not accredited to access the data)
Objectives
Expose an standard grid interface (SRM) for medical image servers (DICOM)
Fulfill application security requirements without interfering with clinical practice
JRA1 All Hands Meeting, CERN

4. Medical Data Retrieval
1. get GUID from metadata
AMGA Metadata
Metadata ACL control
User
Interface
Worker Node
Fireman
gLiteIO
client
In-memory
decryption
2. glite-eds-get
File ACL control
3. get SURL from GUID
gLiteIO
server
7. get file key and decrypt
file locally
4. request file
6. on-the-fly encryption and anonimyzation
return encrypted file
SRM-DICOM
interface
Key ACL control
Hydra
Key store
5. get file key
Anonimization & encryption
DICOM server
JRA1 All Hands Meeting, CERN

5. The DPM + LFC based proposal
As a replacement to FiReMAN.
DPM
SRM v2 implementation, will provide ACLs
ACLs are only controlling one physical replica on local site
Modifications to do
Interface GFAL with encryption
The interface with hydra is planed. Timeline?
Interface the DICOM server with DPM instead of dCache
Jean-Philippe and Daniel started discussing to check how feasible it is.
Provide a coherent file-level ACL control (not just replica-level)
as gLiteIO+Fireman does
JRA1 All Hands Meeting, CERN

6. The DPM + LFC based proposal
What we gain with the move to DPM / LFC
Apparently DPM is more modular than dCache. In a long term we should move to such an SRM implementation.
DPM is interesting for “any biomed storage”
MDM is just an example of one particular case (DICOM servers)
Other biomed data needs encryption/access control (e.g. some bioinformatics databases).
What is needed / has to be done
A coherent grid file-level ACL control mechanism is mandatory
Need to rework on the MDM
No interface with encryption today
JRA1 All Hands Meeting, CERN

7. Hydra KeyStore Repository for encryption keys
Used in the Medical Data Manager (MDM) system
Provides fine-grained (entry-level) access control
Basic permissions and ACLs on entries
Get/Set permission methods
Functionality exposed using the FAS interface (as used by the FiReMAN and the gLite Metadata Interface)
Information being stored
cipher, key, iv (initialization vector), keyinfo
Open Issues
Authorization: changes needed to match DPM/LFC?
JRA1 All Hands Meeting, CERN

8. Delegation Interface How it is done
(Initiator) DELEGATOR
DELEGATEE (Target Service)
Step 1 Proxy Certificate Request
Step 2
Certificate
Request
New Private
Key
Step 3
Certificate
Request
Certificate
Request
Step 4
Sign
Step 5
Existing Proxy
/ Private Key
New Proxy
Certificate
New Proxy
Certificate
Interface defined in a WSDL document
What was in 1.0
Minimal functionality
getProxyReq(String delegationID)
putProxy(String delegationID, String proxy)
Proxies stored in a filesystem
JRA1 All Hands Meeting, CERN

9. Database Backend (MySQL)
Delegation Interface
What is new in 1.1
Semantics defined for the delegation ID
If not given, then hash(clientDN, VOMSAttributes)
More functionality (matching GT4 Delegation)
NewProxyReq getNewProxyReq()
== getProxyReq() with clear delegation ID semantics
renewProxyReq(String delegationID)
destroy(String delegationID)
getTerminationTime(String delegationID)
Abstraction over proxy storage backends
filesystem and database backends are provided
Filesystem Backend
Storage
<dlgee-storage>/<client-dn>/<dlg-id>/usercert.pem
<dlgee-storage>/<client-dn>/<dlg-id>/userkey.pem
<dlgee-storage>/<client-dn>/<dlg-id>/voms.attributes
<dlgee-storage>/<client-dn>/<dlg-id>/termination.time
Storage Cache
<dlgee-storage-cache>/<client-dn>/<dlg-id>/userreq.pem
<dlgee-storage-cache>/<client-dn>/<dlg-id>/userkey.pem
<dlgee-storage-cache>/<client-dn>/<dlg-id>/voms.attributes
Database Backend (MySQL)
CREATE TABLE t_credential (
dlg_id VARCHAR(100), dn VARCHAR(255), certificate TEXT, priv_key TEXT, voms_attrs TEXT, termination_time DATETIME);
CREATE TABLE t_credential_cache (
dlg_id VARCHAR(100), dn VARCHAR(255), cert_request TEXT, priv_key TEXT,
voms_attrs TEXT);
JRA1 All Hands Meeting, CERN

10. Delegation Interface Current Implementations Integration Open Issues
JAVA (org.glite.security.delegation-service-java)
C/C++ in gridsite
CLI tools (org.glite.security.delegation-cli)
Included in gLite 3.1
Integration
Additional portType in the FTS
No code changes needed on the web service
Proxies stored in database to be picked up by agents
CREAM
Open Issues
Interoperability tests
DLGEE KeyPair generation
Currently a new keypair for every request (expensive)
GT4 shares the same key between different requests
Per process, regenerated periodically?
Proxy renewal service
But interface also allows explicit renewal by the client
JRA1 All Hands Meeting, CERN