Skip to content

Provenance Privacy

Raza Ahmad edited this page Nov 30, 2020 · 16 revisions

To preserve privacy while sharing provenance metadata with other hosts in a network, SPADE provides two techniques: sanitization and encryption. The details for both are in the following sections.

Sanitization

Privacy preservation through sanitization performs irreversible transformation on the response Graphs. Under sanitization, a graph annotation or its part is removed from the graph leaving no trace. Annotations of vertices and edges could be sanitized depending upon the sanitization level and scheme defined for each of those levels and annotations. It is available through the Sanitization transformer. There are 3 defined levels of sanitization: low, medium and high. For a given level of sanitization, provenance is individually sanitized for that level. For example, if the level defined is high, provenance is sanitized for the high level only.

To use the transformer, execute the following on the control client:

add transformer Sanitization sanitizationLevel={low,medium,high}

sanitizationLevel defines the level of sanitization to perform before sharing the provenance graphs during this session. The various settings of the sanitization process could be defined in the config file spade.transformer.Sanitization.config whose structure is as follows:

low
cwd,fsgid,fsuid,sgid,suid,remote address[sanitizeIpAddress],path[sanitizePath],time[sanitizeTime]

medium
command line,uid,gid,remote address[sanitizeIpAddress],path[sanitizePath],time[sanitizeTime],size

high
name,euid,remote address[sanitizeIpAddress],path[sanitizePath],time[sanitizeTime],operation

One line in the file contains the sanitizationLevel, followed by a comma-separated list of annotations to sanitize for that level. Each annotation could be followed by the names of custom code handlers for sanitization in square brackets like this: <annotation_name>[sanitizationHandler]. In the absence of these code handlers, the annotation would be sanitized with the default strategy. The various strategies for sanitizing composite annotations are illustrated at the end of the encryption section below.

Encryption

Privacy preservation through encryption performs reversible transformations on the response Graphs. Data is encrypted using Attribute-based encryption (ABE) policy. In this policy, attributes serve as the credentials of a host and a policy is defined over the encrypted data. We consider an attribute as the level of encryption or decryption to perform on the data. In a provenance graph, each annotation of a vertex or edge is encrypted according to the strategy defined for each level in the transformer.

There are 3 defined levels of encryption: low, medium and high. Each of these levels has an associated private key for encryption/decryption, as well as a common public key. The public key and the appropriate private keys have be to shared out-of-band with the other host in order for them to successfully decrypt the data shared with them. For a given level of encryption, provenance is individually encrypted for that level.

Attribute-based encryption is available through the ABE transformer. SPADE use OpenABE implementation available under AGPL 3.0 license. OpenABE could be downloaded and installed for your system from OpenABE GitHub Repository. After installing OpenABE, complete the following steps:

  1. Setup OpenABE and generate master key pair for the Ciphertext-Policy(CP) ABE algorithm.

  2. Generate the private keys for each given set of attributes. A set of attributes corresponds to the level of encryption in our scheme.

  3. Share the master public key and the private key(s) with the party you want to communicate.

The details for each step can be found in the first 6 pages of OpenABE CLI Documentation.

To use the transformer, execute the following on the control client:

add transformer ABE

Strategies

Following are the various strategies for encrypting composite annotations. The same strategies are used for sanitization using Sanitization transformer defined above.

remote address (xxx.xxx.xxx.xxx)

low, the second octet is encrypted.

medium, the third octet is encrypted.

high, the fourth octet is encrypted.

path (w/x/y/z/...)

low, path after first level is encrypted.

medium, path after the second level is encrypted.

high, path after the third level is encrypted.

time (yyyy-MM-dd HH:mm:ss.SSS)

low, day is encrypted.

medium, hour is encrypted.

high, minute, second and millisecond are encrypted.

The various settings of the encryption process could be defined in the config file spade.transformer.ABE.config. In the sample config file below, 'keysDirectory' contains the master public key for encryption and the secret keys used in decryption. After that, one line in the file contains the encryption level, followed by a comma-separated list of annotations to encrypt/decrypt. Each annotation could be followed by the names of custom code handlers for encryption and decryption in square brackets like this: <annotation_name>[encryptionHandler:decryptionHandler]. In the absence of these code handlers, the annotation would be encrypted/decrypted with the default strategy.

keysDirectory=cfg/keys/attributes


low
cwd,fsgid,fsuid,sgid,suid,remote address[encryptIpAddress:decryptIpAddress],path[encryptPath:decryptPath],time[encryptTime:decryptTime]

medium
command line,uid,gid,remote address[encryptIpAddress:decryptIpAddress],path[encryptPath:decryptPath],time[encryptTime:decryptTime],size

high
name,euid,remote address[encryptIpAddress:decryptIpAddress],path[encryptPath:decryptPath],time[encryptTime:decryptTime],operation

Clone this wiki locally