Fabric Data: Secured-By-Design

The Logical Unit

Most database management systems store data in silos, organized according to the type of data stored. For example; customer data, financial data, address data or device data. When data is required, hundreds or thousands of tables may need to be queried using complex joins to deliver the information. This process is very cumbersome, complex and time consuming. Most importantly, data safety is challenged and security is increasingly compromised each time these tables are accessed.

Fabric's unique data approach offers a new paradigm for data management, especially when it comes to protecting data integrity. This approach uses a Logical Unit. Fabric uses the Logical Unit to store and enable access to data using an entity-centric predefined structure that considerably reinforces its security and integrity. This is yet another crucial and unparalleled advantage that Fabric offers in addition to other benefits such as very fast access and high availability of the data.

A Logical Unit is configured by the user for general use and each time data is accessed, a Logical Unit Instance is created, based on a sync policy.

Logical Unit Encryption

Fabric encrypts each Logical Unit Instance (LUI) using an AES256 algorithm and creates a unique encryption key for each LUI. The LUI data can only be read using the Fabric master key, which is also always encrypted.

This additional atomic-level encryption delivers greater protection for sensitive data and entirely eliminates the chance of a large-scale data breach of your systems. Each entity is uniquely protected and its encryption secrets are not relevant to the other millions or more of entities stored in Fabric.

Fabric Hashing Mechanism

The Fabric Masking mechanism uses the SHA-256 algorithm for hashing data.

For example:

  • An Instance Key used to encrypt LU Instances is the hashed combination of the LU name it belongs to, its own LU Instance, and the master key.
  • The Fabric Masking utility uses the SHA-256 algorithm when hashing the original value of any encrypted field of a given LUI.

Fabric Project Encryption

The following illustration shows how Logical Unit Instances inherit their own private encryption keys based on the Fabric master key and the LU to which they belong.

Fabric Master Key

Master Key Generation

Fabric generates master keys using built-in Java methods for AES-256 with GCM (Galois/Counter Mode) key generation algorithms. The master key can be generated by Fabric, or by using the manual Fabric command, and is encrypted using the protection key, if defined.

Once the new master key is generated, it is broken into bytes. Each byte is stored in a separate record in a dedicated Cassandra table. Using Cassandra distribution data logic, the parts of the key are stored across different nodes of the cluster.

The master key is encrypted using a protection key. To do so, the JAVA_AES library randomly generates a new 256 bit key using an AES-256 algorithm. Fabric also uses an Initialization Vector algorithm to encrypt the master key.

Master Key Storage

Fabric generates master keys with or without the Keystore mechanism.

With Keystore

To use a Keystore to hold the master key's protection key, set the MASTERKEY_KEY_STORE_ENABLED parameter of the config.ini file to true.

Without Keystore

Fabric enables the generation of master keys also when a Keystore is not installed. To do so, it generates a new protection key for each master key. When Fabric starts for the first time, a default master key is generated.

A Keystore can be added later and the master key will be re-generated using the Keystore's protection key.

Note that once the Keystore is added to Fabric, it cannot be removed.

Protection Key Storage

The Fabric setup must use a Java keytool to create a Keystore that holds an AES-256 key. This is the protection key. The Keystore is locked by a password and is copied to each node of the Fabric cluster. When starting Fabric, users must key-in the password of the Keystore, otherwise Fabric cannot start.

When a new master key is generated, the master Keystore opens the Keystore, gets the protection key stored in it, and uses it with an initialization vector (IV) to encrypt the Fabric master key. The Keystore contains the history of all encryptions. Each encryption of a master key creates a record in the Keystore with the protection key and the key description of the encrypted master key. This way, when users change the protection key in the Keystore, the previous protection key can still be used to get entities already encrypted by it.

Master Key Commands

The key is generated using the Fabric Activate Key command that activates two components:

  • Key generator
  • Master key store

A key is generated using the following command:

activatekey name='<name>' [generatorType='<generatorType>'] [storeType='<storeType>'] [WITH ARGS='<args>']

For example:

activatekey name='keyProjectX' [generatorType='Java_AES'] [storeType='Stripe_AES']

Master Key Rotation

Master key rotation is another crucial feature provided by Fabric to ensure data security stringency. Although the data is organized and encrypted on a per-instance basis, Fabric users can regenerate keys by setting a regularly scheduled daily or weekly job calling Fabric's rekey function to re-issue the master key and therefore re-encrypt data from all instances.

Note that the job does not have to be time-based but must be triggered by any other condition such as the number of LUIs per node.

Master key rotation enables generating and activating a new master key. The new master key impacts Instance IDs saved in Cassandra from the moment they are generated onwards. The existing Instance IDs are not impacted by the new key until they are next synced and saved in Cassandra.

Upon retrieval of a specific Instance ID, Fabric collects the master key's information used for the encryption of the LU instance and performs on-the-fly de-encryption of the data.

Previous

Fabric Data: Secured-By-Design

The Logical Unit

Most database management systems store data in silos, organized according to the type of data stored. For example; customer data, financial data, address data or device data. When data is required, hundreds or thousands of tables may need to be queried using complex joins to deliver the information. This process is very cumbersome, complex and time consuming. Most importantly, data safety is challenged and security is increasingly compromised each time these tables are accessed.

Fabric's unique data approach offers a new paradigm for data management, especially when it comes to protecting data integrity. This approach uses a Logical Unit. Fabric uses the Logical Unit to store and enable access to data using an entity-centric predefined structure that considerably reinforces its security and integrity. This is yet another crucial and unparalleled advantage that Fabric offers in addition to other benefits such as very fast access and high availability of the data.

A Logical Unit is configured by the user for general use and each time data is accessed, a Logical Unit Instance is created, based on a sync policy.

Logical Unit Encryption

Fabric encrypts each Logical Unit Instance (LUI) using an AES256 algorithm and creates a unique encryption key for each LUI. The LUI data can only be read using the Fabric master key, which is also always encrypted.

This additional atomic-level encryption delivers greater protection for sensitive data and entirely eliminates the chance of a large-scale data breach of your systems. Each entity is uniquely protected and its encryption secrets are not relevant to the other millions or more of entities stored in Fabric.

Fabric Hashing Mechanism

The Fabric Masking mechanism uses the SHA-256 algorithm for hashing data.

For example:

  • An Instance Key used to encrypt LU Instances is the hashed combination of the LU name it belongs to, its own LU Instance, and the master key.
  • The Fabric Masking utility uses the SHA-256 algorithm when hashing the original value of any encrypted field of a given LUI.

Fabric Project Encryption

The following illustration shows how Logical Unit Instances inherit their own private encryption keys based on the Fabric master key and the LU to which they belong.

Fabric Master Key

Master Key Generation

Fabric generates master keys using built-in Java methods for AES-256 with GCM (Galois/Counter Mode) key generation algorithms. The master key can be generated by Fabric, or by using the manual Fabric command, and is encrypted using the protection key, if defined.

Once the new master key is generated, it is broken into bytes. Each byte is stored in a separate record in a dedicated Cassandra table. Using Cassandra distribution data logic, the parts of the key are stored across different nodes of the cluster.

The master key is encrypted using a protection key. To do so, the JAVA_AES library randomly generates a new 256 bit key using an AES-256 algorithm. Fabric also uses an Initialization Vector algorithm to encrypt the master key.

Master Key Storage

Fabric generates master keys with or without the Keystore mechanism.

With Keystore

To use a Keystore to hold the master key's protection key, set the MASTERKEY_KEY_STORE_ENABLED parameter of the config.ini file to true.

Without Keystore

Fabric enables the generation of master keys also when a Keystore is not installed. To do so, it generates a new protection key for each master key. When Fabric starts for the first time, a default master key is generated.

A Keystore can be added later and the master key will be re-generated using the Keystore's protection key.

Note that once the Keystore is added to Fabric, it cannot be removed.

Protection Key Storage

The Fabric setup must use a Java keytool to create a Keystore that holds an AES-256 key. This is the protection key. The Keystore is locked by a password and is copied to each node of the Fabric cluster. When starting Fabric, users must key-in the password of the Keystore, otherwise Fabric cannot start.

When a new master key is generated, the master Keystore opens the Keystore, gets the protection key stored in it, and uses it with an initialization vector (IV) to encrypt the Fabric master key. The Keystore contains the history of all encryptions. Each encryption of a master key creates a record in the Keystore with the protection key and the key description of the encrypted master key. This way, when users change the protection key in the Keystore, the previous protection key can still be used to get entities already encrypted by it.

Master Key Commands

The key is generated using the Fabric Activate Key command that activates two components:

  • Key generator
  • Master key store

A key is generated using the following command:

activatekey name='<name>' [generatorType='<generatorType>'] [storeType='<storeType>'] [WITH ARGS='<args>']

For example:

activatekey name='keyProjectX' [generatorType='Java_AES'] [storeType='Stripe_AES']

Master Key Rotation

Master key rotation is another crucial feature provided by Fabric to ensure data security stringency. Although the data is organized and encrypted on a per-instance basis, Fabric users can regenerate keys by setting a regularly scheduled daily or weekly job calling Fabric's rekey function to re-issue the master key and therefore re-encrypt data from all instances.

Note that the job does not have to be time-based but must be triggered by any other condition such as the number of LUIs per node.

Master key rotation enables generating and activating a new master key. The new master key impacts Instance IDs saved in Cassandra from the moment they are generated onwards. The existing Instance IDs are not impacted by the new key until they are next synced and saved in Cassandra.

Upon retrieval of a specific Instance ID, Fabric collects the master key's information used for the encryption of the LU instance and performs on-the-fly de-encryption of the data.

Previous