Cost of End-To-End Encryption

Cost of End-To-End Encryption (Lack of Intrusion Detection / Prevention in Encrypted Traffic)

End-to-end encryption has its cost.  Intrusion Detection and Prevention Systems (IDS and IPS)  are unable to analyze encrypted traffic and attack vectors may get through the iDS / IPS if the traffic is in an encrypted format.  Encryption should be maintained as close to the Destination Server as possible.  Once the traffic is in a secure site, the traffic can be decrypted for analysis by Firewalls, IDS and IPS devices before they reach their Destination Servers.

IDS and IPS devices by themselves are incapable of decrypting and re-encrypting traffic.  Until this technology is developed, there is a risk of data sniffing at the last mile where the IDS / IPS is setup.  But this risk could be significantly lower than the risk of malicious traffic reaching your destination servers.  The risk of data sniffing could be further reduced by securing the DC, segregating the last mile communication into separate VLAN and turning off port mirroring for the VLANs concerned.


Cost of End-To-End Encryption

Password Management at the Application Server

External Module Password Management at the Application Server

  • Do not hardcode secrets (example: passwords, private keys, etc) in source code.
  • Keep secrets in a separate centralized configuration file, that can be referenced by different application modules.  The configuration file should have much restrictive access permissions.  It should not be added to Version Control Programs.  It should not be in the downloadable path of any web application.
  • Keep the configuration file contents encrypted using a separate application password.  The application can decrypt the file on-the-fly to retrieve the secret information and leave the file encrypted after use.
  • If the configuration file contents cannot be encrypted, at least store them in encoded format (Base 16, Base 32, Base 64, etc), so that they cannot be easily memorized.
  • Access to the configuration file should also be logged by the Operating System into a Central log server.


Password Management at the Application Server

Cryptographic Key Management

Cryptographic Key Management

What are the common cryptographic keys in use?

  • Asymmetric keys for PKI
  • Asymmetric keys for SSL tunnel creation
  • Symmetric keys used for encryption of data

How does the Web Server / Load Balancer create the SSL session key for encrypting each session with the Client browser?

The secret session key for an SSL session is derived from a pre-master secret created by the client browser using its OS’s inherent random number generator.  The browser encrypts the pre-master secret with the server’s public key and sent to the server.  The server uses the pre-master secret to derive the secret key for further onward encryption of the data transferred in the SSL session.  The secret key is stored in cache only and is purged after the session expires.

How does proprietary Database, Fileserver, Data Backup Solution Server encrypt data?

Case-in-Point: Oracle Transparent Database Encryption (TDE).

  • Uses built-in Key Management solution.

Case-in-Point: EMC Data Domain which can be used as a Data Backup and Recovery Solution.  It provides the below options for Data-At-Rest encryption:

  • Static Key managed internally.
  • Internal Key Management for periodic Key Rotation.
  • External Key Management is allowed through RSA Data Protection Manager (DPM) server.

Case-in-Point: EMC VNX series of Storage Devices which could be used as a File Server.

  • Includes a Keystore, which is an embedded and independently encrypted container which holds all the Data-at-Rest Encryption keys on the data arrays.  The data array has an internal key manager called VNX Key Manager.  External key managers are not supported.

Key Management Solution (KMS)

A key management solution (KMS) is an integrated approach for generating, distributing and managing cryptographic keys for devices and applications. Compared to the term key management, a KMS is tailored to specific use-cases such as secure software update or machine-to-machine communication. In an holistic approach, it covers all aspects of security – from the secure generation of keys over the secure exchange of keys up to secure key handling and storage on the client. Thus, a KMS includes the backend functionality for key generation, distribution, and replacement as well as the client functionality for injecting keys, storing and managing keys on devices. With the Internet of Things, KMS becomes a crucial part for the security of connected devices.

There are many proprietary KMS.  Example: RSA Data Protection Manager, Amazon Web Service KMS, HP Enterprise Security Key Manager, Oracle Key Manager, Safenet Enterprise Key Management.

Use of Hardware Security Module (HSM) for the protection of Cryptographic Keys

A hardware security module (HSM) is a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server.  HSMs may possess controls that provide tamper evidence such as logging and alerting and tamper resistance such as deleting keys upon tamper detection. Each module contains one or more secure cryptoprocessor chips to prevent tampering and bus probing.  Many HSM systems have means to securely backup the keys they handle either in a wrapped form via the computer’s operating system or externally using a smartcard or some other security token.  Because HSMs are often part of a mission-critical infrastructure such as a public key infrastructure or online banking application, HSMs can typically be clustered for high availability. Some HSMs feature dual power supplies and field replaceable components such as cooling fans to conform to the high-availability requirements of data center environments and to enable business continuity.

A hardware security module can be employed in any application that uses digital keys. Typically the keys must be of high-value – meaning there would be a significant, negative impact to the owner of the key if it were compromised.  The functions of an HSM are:

  • onboard secure cryptographic key generation
  • onboard secure cryptographic key storage and management
  • use of cryptographic and sensitive data material
  • offloading application servers for complete asymmetric and symmetric cryptography

HSM are also deployed to manage Transparent Data Encryption keys for databases.  HSMs provide both logical and physical protection of these materials, including cryptographic keys, from non-authorized use and potential adversaries.  The cryptographic material handled by most HSMs are asymmetric key pairs (and certificates) used in public-key cryptography.  Some HSMs can also handle symmetric keys and other arbitrary data.

Use of HSM for End-to-End Encryption of User Password

HSM mainly provides end-to-end encryption of the User Password – [i] Browser to HSM Flow; and [ii] HSM to Application Database Flow.  This is  through secure generation of Asymmetric key pairs on demand (for end-to-end encryption of User Password from Browser to HSM) and secure management of a Symmetric key for storage of User Password in an encrypted format in an external Database (for end-to-end encryption of User Password from HSM to Application Database).  The User Password remains in an unencrypted form only at the User’s Browser.  The User Password remains in a cleartext-hashed format at both the User’s Browser and the HSM, but nowhere else.

General HSM Security Features

  • Provide strong physical and logical protection of cryptographic keys – Asymmetric key pairs and Symmetric keys.
  • Asymmetric key pairs are created to handle User Authentication.  Public key created will be passed to the application server who passes it to the application client.  The application client encrypts the user password hash with the public key.  The user password hash will be retrieved by the HSM by decrypting using the private key.  The user password hash will then be encrypted with a secret key and passed to the application server for storage in its LDAP or Database.  Both the values – user password hash encrypted with public key and user password hash encrypted with secret key – will be passed back to the UAS for matching and authentication of a User.
  • Only allow connectivity from pre-defined servers using IP restriction.
  • Configuration of HSM only allowed by physically visiting the HSM at the Datacenter with the physical Keys and User ID/Password credentials.
  • Installation and configuration of HSM driver is needed at the connecting server before connection establishment.
  • Support for High-Availability clustering supported by configuration in the HSM driver.

PKI environment (CA HSMs)

In PKI environments, the HSMs may be used by certification authorities (CAs) and registration authorities (RAs) to generate, store, and handle key pairs. In these cases, there are some fundamental features a device must have, namely:

  • Logical and physical high level protection
  • Multi-part user authorization schema
  • Full audit and log traces
  • Secure key backup

On the other hand, device performance in a PKI environment is generally less important, in both online and offline operations, as Registration Authority procedures represent the performance bottleneck of the Infrastructure.

Card payment system HSMs (bank HSMs)

Limited-feature HSMs are used in card processing systems. These systems are usually less complex than CA HSMs and normally do not feature a standard API. These devices can be grouped in two main classes:

OEM or integrated modules  – for automated teller machines and point of sale terminals:

  • to encrypt the personal identification number (PIN) entered when using the card
  • to load keys into protected memory

Authorisation and personalisation modules:

  • check an on-line PIN by comparing with an encrypted PIN block
  • in conjunction with an ATM controller, verify credit/debit card transactions by checking card security codes or by performing host processing component of an EMV based transaction
  • support a crypto-API with a smart card (such as an EMV)
  • re-encrypt a PIN block to send it to another authorisation host
  • support a protocol of POS ATM network management
  • support de facto standards of host-host key|data exchange API
  • generate and print a “PIN mailer”
  • generate data for a magnetic stripe card (PVV, CVV)
  • generate a card keyset and support the personalisation process for smart cards

The major organization that produces and maintains standards for HSMs on banking market is the Payment Card Industry Security Standards Council.



Cryptographic Key Management

Encryption for Portable Hard Disks

Encryption for Portable Hard Disks for Huge Data Transfer

Full Disk Encryption may be achieved by using Bitlocker for Windows or FileVault for MAC.  Please refer to this link:

Further References:

Encryption for Portable Hard Disks

Data Transfer Security

Added Data Transfer Security

In addition to securing data transfers through a secure channel (SFTP, FTPS, SCP, etc), the data files should be encrypted (PGP, Winzip, etc).  This ensures that even if the files were transferred to a wrong recipient, the recipient would not be able to decrypt the contents without the file encryption keys.


FTPS is FTP using the SSL protocol for encryption. This is different from the SCP/SFTP family of protocols which use SSH as their transport tunnel. You will usually use the same client programs for scp and sftp (WinSCP for instance; SFTP is an upgraded version of SCP), whereas you usually use a web browser or web Download manager (like filezilla) for FTPS. FTPS is web-based, whereas SFTP is based on secure shell protocols pioneered on *NIX systems.  FTPS use has been waning for a very long time now, and is usually used in niche circumstances these days.  The SSH family is a set of protocols focused on server administration and remote access to the servers processing capability, rather than simple content distribution. it would allow privledged users of a system to connect to a shell to perform work on the server itself, and many file management tasks related to that work involve transferring files between the localhost and the server, which is why SCP and eventually SFTP were developed.


Data Transfer Security

Encryption of Data-At-Rest

 Approaches for Encryption of Data-At-Rest

  • Application Encryption
  • Disk Encryption
  • Database Encryption

Application Encryption

You can task a given application with encrypting its own data. This encryption capability is designed into the application itself, and organizations will not have to add another solution for encrypting data across the network. By the time the database receives the data, it has already been encrypted and then stored in the database in this encrypted state.

The solution can be implemented at the application layer or the database layer via an API.

A benefit to application encryption is that the data is only accessible to authenticated, authorized application users. If an attacker, whether an insider or outsider, tried to access the data directly within the database without going through the application, the data would be encrypted and inaccessible.

The disadvantages to application encryption include:

  1. Significant changes required in the application and/or database layer: First, to implement application encryption you must make significant changes in both the application layer and the database layer. Applications accessing the data need to be modified to understand and implement encryption. This could mean changing literally hundreds of applications for some organizations. In addition, the database tables and views that reside in the database and support the application need to be changed because the values being stored will no longer match the external data type representation. For example, a nine-digit SSN could not be encrypted and stored in the same field or data type that was originally used to store the unencrypted SSN. Complicating the situation further is the fact that many organizations do not even know all the applications that may be accessing the data. Some applications, such as legacy applications, may also make it extremely difficult, if not impossible, to implement this solution.
  2. Database performance issues: Second, database performance issues may arise because external applications control the encrypted data within the database. For example, if the application layer is doing the encryption, indexes and search capabilities within the database will not work. Alternatively, a database layer encryption solution can be implemented using an API, but that requires applicable triggers and views, which also introduce additional overhead, thus affecting database performance.
  3. Difficult Key Management: Finally, consider key management. Because multiple applications may be doing the encryption then sending to the database, keys are stored in many locations, introducing additional exposure points. When it is time to change the key, this may mean decrypting all the data with the old key and re-encrypting all the data with the new key—a significant impact to the environment.

Disk Encryption

Typically, disk encryption requires operating system support hooks to encrypt database files or the media on which the files reside. In these cases, keys typically must be managed by system or storage administrators. With file and disk encryption, there is no need to change the application(s) to accommodate encryption to the database with application encryption. In addition, file/disk encryption is a concept that organizations tend to be familiar with because it is similar to laptop encryption that many organizations have already implemented.

Because the encryption is occurring at the file or disk level, everyone with access to the operating system typically has access to all the data encrypted on that system.

Database Encryption

Database encryption falls somewhere between application encryption and disk encryption.

With Transparent Database Encryption (TDE), the encryption process and associated encryption keys are created and managed by the database. This is transparent to database users who have authenticated to the database. At the operating system, however, attempts to access database files return data in an encrypted state. Therefore, for any operating system level users, the data remains inaccessible. Additionally, because the database is doing the encryption, there is no need to change the application(s), and there is a minimal performance overhead when changes occur in the database.

A disadvantage to TDE is that the data is not protected from authenticated, authorized database users, including the DBA.

Encryption Approaches – Software Encryption vs Hardware (Appliance Based) Encryption

Hardware based encryption is deemed faster and more efficient than Software based encryption as dedicated hardware components are used for the heavy data crunching instead of precious CPU cycles.



Encryption of Data-At-Rest

Patch SSL Vulnerabilities in your Browser and Server

Patch SSL Vulnerabilities in your Browser and Server

Use SSL Labs to test your Browser and Server for SSL vulnerabilities.  The most common vulnerabilities and how to patch them are mentioned below:

1) Certificate uses weak hashing algorithm (example: MD5, SHA-1, etc)

Get new SSL certificates issued with the latest hashing algorithm (example: SHA-2, SHA-3)

2) SSL v2 / v3, which are vulnerable versions of SSL, are supported by the browser / server.

Update your browser to the latest version.

To mitigate server side SSL vulnerabilities, please refer to  to learn about the best SSL configuration for common server platforms.

3) Forward Secrecy is not enabled.

The ordering of a ciphersuite is very important in deciding which algorithms are going to be selected in priority. The recommendation in the mozilla link above prioritizes algorithms that provide perfect forward secrecy.

4) Weak cipher suites are enabled.

Refer to the recommendations in the mozilla link above for common servers.

4) Vulnerable to SSL Fallback attack.

Upgrade to the latest version of OpenSSL which supports the TLS_FALLBACK_SCSV implementation which prevents an SSL protocol downgrade attack.

Note: For IBM HTTP Servers, refer to this link to learn more about how to configure SSL.  The commands are not covered in the mozilla link above.  But, the idea is to learn from the mozilla link and implement using the IBM proprietary directives mentioned in the IBM link.


Patch SSL Vulnerabilities in your Browser and Server