Page History

Content can be stored encrypted in StageRSTageR . If enabled, STageR StageR uses the uses the aes-256-cbc algorithm, of the NodeJS crypto library, using an Initialization Vector (IV) and a Data Encryption Key (DEK) provided by a key manager.Content is encrypted at the scope level and a enckeyid tag is added to each encrypted content scope.

The option can be enabled/disabled per Storage Unit through the administration API.

PUT admin/enableContentEncryption/<storage-unit>/<true-false>

A key manager is a pluggable module that provides data encryption keys (DEK) to the application. The internal implementation of the key manager is up to the users needs. The module needs to provide a way to get a DEK given a enckeyid.

var crypto = require('crypto')

function basicKeyManager (options) {
  var masterKey

  if (!options.masterKey) {
    throw new Error('options.masterKey is required')
  }

  masterKey = options.masterKey

  return {
    generateiv: function () {
      // IV needs to be 16 bytes
      return crypto.randomBytes(16).toString('base64')
    },
    generateKeyId: function () {
      return 'localKey'
    },
    getDek: function (storageUnitName, key, callback) {
      if (key === 'localKey') {
        return callback(null, masterKey)
      } else {
        return callback(new Error('Invalid Dek key: ' + key))
      }
    }
  }
}

module.exports = basicKeyManager

Key Manager Implementation Options

StageR provides STageR provides 3 base key manager implementations.

1 - Basic

Uses a single master DEK set as a configurable parameter.

Configuration:

keyManager:{
    type:'basic',
     basic:{
         masterKey:'MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMzI='
     }
 }

2 - File Based Master key

A file containing a list of master keys to encrypt the DEKs that will be used to encrypt content. There will be a finite number (configurable) of DEKs per Storage Unit that will be stored in a Mongo database (DEK). The DEK table will storage the encrypted DEK, the version of the master key and the IV used to encrypt the DEK. The Master Key file location is set as a configurable parameter of this key manager.

File Example:

MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTE=   9
?MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI    5
?MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTM    7

Configuration:

keyManager:{
    type:'filebased',
    keysNumber: 1000,
    filebased:{
        masterKeyLocation: 'config/MasterKey.txt'
    }
}

3 - Hadoop KMS

Uses Hadoop Key Management Server for DEK encryption. Based on a master key from KMS, the key manager uses this to generate new keys that will be used to encrypt the DEKs. There will be a finite number (configurable) of DEKs per Storage Unit that will be stored in a Mongo database (DEK). The DEK table will store the encrypted DEK, the iv, the master key and a proxy key/iv pair from KMS that were used to encrypt the DEK.

Configuration:

keyManager:{
    type:'clouderakms',
    keysNumber: 1000,
    clouderakms:{
        masterKey:'master_key_1',
        server: 'server-name',
        port: '16000',
        user: 'hdfs',
        sslEnabled: true,
        sslOptions: {
            keyLocation: './config/sslcerts/kms/sr_client_key.pem',
            certLocation: './config/sslcerts/kms/sr_client_cert.crt',
            caLocation: './config/sslcerts/kms/cacert.pem',
            passphrase: 'sibiu7$',
            requestCert: true,
            rejectUnauthorized: true
        }
    }
}