With 4D, you can encrypt your data to ensure its confidentiality, whatever the context of use. In particular, encryption in 4D has the following key features:

• The ability to encrypt sensitive data within a database - but not necessarily the whole data file,
• An additional security layer to protect data access,
• Non hardware-based encryption, you control the key (corresponding to requirements for using external hosting companies).

Note: For more information on how 4D handles security questions, please refer to the 4D Security Guide.

4D offers two different encryption modes, which meet two different needs:

• Asymmetric encryption, based upon a pair of keys. Encryption is performed with the public key, while decryption requires the private key.
  This mode is suitable to secure data exchanges over a network, since it allows authentication and encryption.
  In 4D, it is implemented by the GENERATE ENCRYPTION KEYPAIR, ENCRYPT BLOB and DECRYPT BLOB commands. 

• Symetric encryption, where the same key is used for both encryption and decryption (AES-256 algorithm).
  This mode is suitable for local data encryption. It is supported by the commands of the Data Security theme, such as Encrypt data BLOB and Decrypt data BLOB.

Data encryption in 4D is based upon the following concepts:

• Granularity: Encryption is done at the table level. Tables containing sensitive data are flagged as "encryptable" in the database structure (.4db file). For more information on how to configure encryptable tables, please refer to the Encryptable paragraph.
• Encryption key: Tables are encrypted by an AES key, generated using a SHA-256 algorithm from a given "passphrase". The encryption key can be stored in a file on an external device such as a USB key, that could be connected to the server only when necessary.
• Keychain: Once a valid encryption key has been provided for an encrypted data file, it is kept in memory in the 4D keychain. Thus, the data file can be closed and reopened without providing the key (via a device or with the ds.provideDataKey( ) method). In client/server configuration, the keychain is stored on the server. The keychain is emptied when 4D quits.
• Passphrase: The passphrase is a more secure version of a password, it can contain a large number of characters and is used to generate the encryption key. The same passphrase will always result in the same encryption key.
• Symetric encryption: The same encryption key is used to encrypt and decrypt data.
• Reading and writing encrypted data: Once a valid encryption key has been provided to an encrypted data file:
  
  • all data modifications in encryptable tables are automatically encrypted on disk
  • all data loaded from encryptable tables is automatically decrypted in memory
• Target files: Encryption is applied to all files handling data: .4dd, .journal, .4dIndex.

Warning: If the encryption key and the passphrase are lost, it will be impossible, even for 4D technical services, to access the encrypted data. 

Encryption in 4D is based upon a simple, two-step scenario:

Step 1: Selecting tables to encrypt

• The developer selects tables to be encrypted at the database structure level (see Encryptable).
• For perfomance reasons, only tables containing sensitive data need to be selected. 
• No encryption is done at this step, users can work normally, without data encryption.

Step 2: Encrypting selected data

• When deploying an application (if requested by the customer), the developer enables encryption using the Maintenance and security center (MSC), or with the 4D language.
• Encryption is then propagated to all pre-selected tables. 
• Encrypted data is automatically decrypted when read and re-encrypted when saved, if the encryption key has been provided. 

Note: The 4D keychain is only valid during the running 4D session. It is kept in memory and is automatically deleted when the 4D application is closed.

This graphic includes the following steps:

1. When the user tries to open an encrypted data file, 4D looks for a valid encryption key in the 4D keychain. If found, access (read/write) to the encrypted data  is granted.
2. If no valid encryption key is found in the 4D keychain, 4D scans all connected devices (at first level) to find a .4DKeyChain file containing a valid encryption key (see Storing data encryption keys in files below).
3. At this step, the data file is actually open. If no valid encryption key is provided, no read/write access is possible on encrypted data.
4. The user can, however, provide a valid data encryption key by:
   
   • connecting a device containing the .4DKeyChain file and calling the Discover data key command,
     or
   • entering the passphrase with the ds.provideDataKey( ) method.

   If a valid data encryption key is provided, read/write access is allowed on encrypted data.

5. Each time a valid encryption key is found, it is added to the 4D keychain. A connected device containing an encryption key does not need to remain connected once the encryption key has been added to the 4D keychain. 

You can create data encryption key files in order to store them on external devices (e.g., USB keys or external disks) so that 4D can use them automatically at startup or after a call to Discover data key to decrypt data (see above). Once a valid encryption key has been found, it is stored in memory in the 4D keychain and used during the entire session. At this step, the external device can be disconnected.

An encrypted key file must comply with the following rules:

• The file name must have the .4DKeyChain extension. For example, "myKeys.4DKeyChain".
• It must be a text file formatted in JSON.
• It can contain one or more encryption key(s) and/or passphrase(s) in JSON objects or collections of objects; each object must contain an encodedKey or passPhrase property. See the New data key command to learn how to generate a key file. 
• The file must be stored at the root of the external device
• Multiple .4DKeyChain files can be used simultaneously.

Note: The contents of all found .4DKeychain files are analyzed to detect whether a key matches the data, regardless of the file names.

Here is an example of a key file containing three keys: