3.6 Context-Aware Storage
5.1.6 The User-Role Model
In the SOS, data ownership and protection are achieved through the user-role model. This model consists of two concepts: the user and the role. In the SOS the concept of user is associated with the one of a real-life user that interacts with the SOS. For example, each of the three people ‘Simone’, ‘Al’, and ‘Graham’ can be associated with a respective named user entity. A user interacts with the SOS through one or multiple roles. The role is an SOS entity that users use to: (I) define ownership of content; (II) digitally sign manifests; (III) and protect content via encryption. Examples of user-role relationships are the following:
• The user ‘Simone’ is associated with the ‘Home’ and ‘PhD’ roles; • The user ‘Al’ with the ‘Home’, ‘Work’, and ‘Photographer’ roles; and • The user ‘Graham’ with the ‘Home’, ‘Work’, and ‘Runner’ roles.
5.1. The Sea of Stuff Model
The User
The relevant attributes of theuser entity are its name and a pair of asymmetric keys, used to digitally sign/verify content. The name is a human-readable string that allows SOS users to informally refer to end-users. The private key is used for the creation of all the roles associated with the user (see next Section), while the public key is used to verify such roles. The generic scheme of theuser manifest is shown in Manifest 5.8.
{
"type" : "User",
"guid" : <hash(type, name, d_public_key)>, "name" : <User name>,
"d_public_key" : <public_key> # public key for digital signatures }
Manifest 5.8: User Manifest.
The Role
The role entity consists of two key pairs, one to digital sign manifests, as explained in Section 5.1.6.2, and one to protect content, as explained in Section 5.1.6.3 (see Mani- fest 5.9). A role is always associated to a user and signed using the user’s private key. {
"type" : "Role",
"guid" : <hash(type, user, name, signature, d_public_key, public_key)>, "name" : <Role name>,
"user" : <User GUID>,
"signature" : <as signed by User>,
"d_public_key" : <public_key>, # public key for digital signatures "public_key" : <public key> # public key for content protection }
Manifest 5.9: Role Manifest.
The user and role manifests will be represented as in Figure 5.16. The three function- alities provided by the role — ownership, manifest signature, and content protection — are discussed in more details in the next subsections.
Type: User GUID: user-ref Name: user-name d_pub_key: pub-key (a) Type: Role GUID: role-ref User: user-ref Name: role-name Signature: signature d_pub_key: pub-key
Public Key: pub-key
(b) Figure 5.16: Diagrams for the user and role entities.
5.1.6.1 Ownership
Content ownership is established by referencing a role from the metadata of a given version. Moreover the metadata can be used to store not only the owner of a version, but also other types of role relationships (e.g., author, tester, client, stakeholder,etc.).
{
"type" : "Metadata", "guid" : <hash(properties)>, "properties" : [
{
"key" : "owner", # This could also be author, tester, client, stakeholder, etc. "type" : "guid",
"value" : <reference to role> }
], ... }
Manifest 5.10: Metadata manifest in JSON format containing theowner property.
5.1.6.2 Signing Manifests
The role entity allows manifests to be digitally signed and therefore to have authenti- cation and non-repudiation, in addition to integrity, over the content of the manifest. The atom manifest acts only as a means to abstract data from its locations, so ensuring data integrity via the GUID field is enough. In the case of the other manifests, however, the digital signature can be used to demonstrate the authenticity of its content. For example,
5.1. The Sea of Stuff Model
if the role ‘PhD’ by the user ‘Simone’ digitally signs a certain compound manifest, then anyone can verify that the manifest was signed by the role ‘PhD’ and that no one has tampered with it. It should also be remembered that the ‘PhD’ role manifest itself is signed by the user ‘Simone’, so the same properties can be verified for the role manifest. Figure 5.17a shows the relationship between a compound manifest, its role signer and its matching user. A signed manifest is created by adding the signer and signature fields to it (see Manifest 5.11).
{
"type" : <Manifest Type>, "guid" : <hash(Content to Hash)>, "signer" : <guid of signer role>,
"signature" : <sign(Content to Sign)>, # The content to sign depends on the type of manifest ...
}
Manifest 5.11: Base Signed Manifest JSON structure.
Type: Compound
Compound Type: collection/data
GUID: compound-ref
Signature: signature
label x content
signer TypeGUID: Role: role-ref
Name: role-name Signature: signature d_pub_key: pub-key Type: User GUID: user-ref Name: user-name d_pub_key: pub-key user
Type: manifest type
GUID: reference
...
Type: Version Invariant: invariant-ref GUID: version-ref Signature: signature signer content Type: Role GUID: role-ref Name: role-name Signature: signature d_pub_key: pub-key Type: User GUID: user-ref Name: user-name d_pub_key: pub-key user
Type: manifest type
GUID: reference
...
(b)
Figure 5.17: Diagrams for signed manifests. (a) illustrates a compound being signed, while (b) shows an analogous relationship for a signed version manifest.
5.1.6.3 Protecting Content
Manifests and atoms, as seen so far, are stored in clear text. Hence, anyone who has access to them is able to read them. The role entity allows manifests and atoms to be protected using a combination of symmetric and asymmetric encryption.
Protecting Content
Content in the SOS is protected by encrypting it using a symmetric encryption mecha- nism (e.g., AES). The symmetric key is randomly generated and then encrypted using the public key of the role. The pair composed by the role GUID and the encrypted symmetric key is then added to the manifest of the protected entity as shown in Manifest 5.12. The generic algorithm to protect content in the SOS using roles is described in pseudo-code in Algorithm 1. In the SOS, protection can be applied at different granularities because not all entries have to be necessarily encrypted. For example, one may want to protect atoms and compounds, but not the metadata describing them. The content to encrypt depends on the type of entity:
• Atom: the actual atom is encrypted (see example shown in Figure 5.18 and the resulting protected manifest at Manifest 5.13).
• Compound: the list of contents in the manifest is encrypted. • Metadata: the list of properties in the manifest is encrypted.
5.1. The Sea of Stuff Model
{
"type" : Protected Manifest Type, "guid" : <hash(contents)>, ...,
"keys" : [ {
"key" : <encrypted key>, "role" : <role guid> } ]
}
Manifest 5.12: Protected manifest in JSON format.
{
"type" : "Atom Protected",
"guid" : "54842", # hash(encrypted atom) "locations" : [ {
"type" : "persistent",
"location": "sos: //09102/54842" } ],
"keys" : [ {
"key" : "192a+=" # <encrypted(symmetric_key)>, "role" : "09af9"
} ] }
Algorithm 1:Generic algorithm to encrypt any content in the SOS through the role.
Input: Content C to protect
Result: Encrypted contentC0 and encrypted keyKR
begin
1. Generate a random symmetric keyK 2. EncryptC withK →C0
3. EncryptK with the public key of role R, Rpub k →KR
4. Store the manifest with the pair: (KR, R).
The manifest can store multiple (key, role) pairs. 5. if C is an atom, then storeC0
6. if C is not an atom, then embed C0 as part of the manifest
end Type: Atom GUID: f1544 Encrypt with random symmetric key Type: Role GUID: 09af9 Name: Home Signature: 42sxj+= pub_key: fsr8a/= Type: User GUID: 44e8a Name: Simone d_pub_key:42s4a user hash f1544 54842 Type: Atom P. GUID: 54842 Locations: [ ... ] Keys: [ { Role: 09af9 Key: 192a+= } ] Encrypt with private key 192a+= Manifest Creation Role GUID 09af9 (1) (2) (2) (2) (3)
5.1. The Sea of Stuff Model
Reading Protected Content
Protected content can be read only by the roles that are listed in the keys field of the protected entity manifest. If the role is listed, then it must decrypt the associated encrypted key using its private key and use the decrypted key, which is the same symmetric key used to protected the content, to read the protect entity. The generic algorithm to read protected content using roles is described in pseudo-code in Algorithm 2.
Granting Access
The process of a role (granter) granting access to a protected entity to another role (grantee) involves three steps:
• The encrypted key associated to the granter should be decrypted using the granter private key.
• The decrypted key should be re-encrypted using the public key of the grantee. • The grantee’s GUID and the new encrypted key should be added to the manifest (in
thekeys field).
Algorithm 2:Generic algorithm to read encrypted content through a role.
Input: Encrypted contentC0 to read
Result: Decrypted contentC
begin
1. Get the manifestM forC0
2. Get the keyKRi for the role Ri fromM, wherei is one of the roles stored in the key
set of the manifest
3. Decrypt KRi with the private key of R, Rpriv k →K
4. Decrypt C0 usingK →C