Townsend Security Data Privacy Blog

One of the most common questions we get here at Townsend Security is something like “Who has access to my encryption keys in AWS?” It is a natural question to ask and it can be hard to determine the answer to this question with many key management solutions - including the key management services provided by Amazon. Let me try to answer this question for our Alliance Key Manager for AWS.

Alliance Key Manager for AWS runs as a stand-alone EC2 instance in Amazon Web Services. There is no component of Alliance Key Manager that is shared by other users of AWS, and there is no component of Alliance Key Manager that uses encryption key management services provided by Amazon in AWS. Neither Amazon nor Townsend Security hold any credentials that grant access to the key manager solution, and there are no “backdoors” to the key manager. You, the AWS customer, solely and exclusively manage it.

Encryption keys in Alliance Key Manager are managed by the Alliance Key Manager Administrative Console. This is an application that you install on your PC and which accesses one or more instances of Alliance Key Manager in AWS. While you could install the administrative console in an EC2 instance in AWS, we recommend that you install it on a secure PC outside of AWS. You maintain full control over the application used to manage keys.

The administrative console connects to Alliance Key Manager over a secure TLS session using certificates that are issued by the Alliance Key Manager instance. That is, only administrators using PKI certificates known and authenticated by the specific key manager are allowed to perform management functions.

The use of encryption keys by applications or users inside of AWS or outside of AWS is likewise controlled by secure TLS sessions that are also validated to the specific key manager instance and certificate authority. Just having a valid certificate from Verisign or other certificate authority is not adequate to gain access to encryption keys.

An additional layer of encryption key access control allows you to restrict an encryption key to a user or group as defined on the client-side certificate. This level of key access control leverages to Common Name (CN) and Organizational Unit (OU) of the client-side certificate to control access to a key. If you specify that a key can only be accessed by user “Bill” in the group “Sales”, then Alliance Key Manager will inspect the connecting session to be sure that the certificate Common Name contains the value “Bill” and that the certificate Organizational Unit is “Sales”. Access is denied unless this rule is met.

Lastly, if an unauthorized user gains access to the Alliance Key Manager encryption key database they will not have access to the actual encryption keys. Data encryption keys (DEK) are encrypted by key encryption keys (KEK) which are stored separately. A stolen backup or copied key database file will be insufficient to gain access to the encryption keys.

You should be aware that any cloud service provider has low level access to your virtual machines and storage. That is true of Amazon’s cloud platform as it is with any other cloud platform. And you should also be aware that Amazon and other cloud service providers must obey the laws and regulations of the countries in which they operate. You cannot exclude the possibility that Amazon will provide access to your key management EC2 instance if required to do so under the law. In some countries this means that law enforcement organizations, national security agencies, and other governmental actors may have access to your encryption keys. And, while very unlikely, you cannot exclude the chance that an Amazon employee might make an unauthorized access to the EC2 instance of your key server. If these possibilities make you feel uncomfortable you should consider hosting your key management server outside of AWS. Townsend Security's Alliance Key Manager solution can be hosted in your data center or in a hosting facility that you designate for this and provide keys to your AWS applications.

You can find more information about Alliance Key Manager for AWS here.

VMware customers have experienced some frustration around cloud migrations for quite some time. While VMware has attempted to provide a path to the cloud through their vCloud strategy, substantial barriers have made the migration difficult to achieve. While VMware customers have achieved substantial cost and efficiency savings through VMware technologies, they have largely not been able to extend these benefit through cloud migrations. The new IBM and VMware partnership is changing this.

There are two aspects of the partnership that make this very different than other cloud offerings for VMware:

• IBM will create dedicated cloud resources for VMware customers who migrate, essentially creating a private cloud platform. This will alleviate many of the concerns of Enterprise customers about the security of their cloud migration.

• IBM has negotiated great pricing for VMware applications on the IBM SoftLayer cloud. This will let VMware customers experience an immediate ROI on the cloud migration.

VMware customers have invested a great deal in the architecture and administration of their VMware environments. VMware applications let customers create secure segmented networks, apply security and access controls, monitor the status of their applications, automate business recovery operations, and perform an number of other administrative functions in a coherent and cost-effective manner. Finding a way to the cloud that leverages benefits is crucial for the VMware customer.

I think IBM has found the right path for these customers.

IBM is not the first to attempt to address the needs of the VMware customer. Rackspace and others have cloud migration plans and have been working with VMware customers. But I think IBM SoftLayer has solved some problems that will open the path to VMware in the cloud.

One of the remaining challenges for VMware customers is to get their third-party application and security vendors to embrace this move to the cloud. While the IBM VMware offering is a true native VMware implementation that will reduce the technical issues, software vendors need to be explicit about their support for solutions deployed on a cloud platform. VMware customers can find it confusing and frustrating to get clear statements of support from vendors.

At Townsend Security we are trying to support our customers migrating our products in VMware to the IBM SoftLayer cloud. Our Alliance Key Manager and related encryption products are already validated for deployment in VMware. And we’ve extended our support for the VMware platform by validating our encryption and key management to the PCI Data Security Standard. We now also support the migration or deployment of our solutions in the IBM SoftLayer cloud. This gives IBM SoftLayer customers the confidence of moving their encryption security infrastructure to the IBM SoftLayer platform.

It has been amazing how the PCI-DSS validation of our solutions in VMware have helped VMware customers meet PCI requirements. VMware deserves a lot of credit for creating a formal program for PCI validation on a well-defined VMware reference architecture. Working with Coalfire, a security auditing firm, we were able to very quickly certify our encryption and key management solutions to the PCI-DSS standard. This has helped multiple customers quickly move through the compliance challenge and this applies to the IBM SoftLayer platform, too. Because IBM SoftLayer retains the dedicated resources for the customer, compliance will be easy to achieve.

IBM and VMware have created a great path to the cloud for VMware customers. I know that many challenges will remain for customers with more complex VMware architectures, especially with hybrid environments. But I think the path to the cloud just got a bit straighter and easier.

Patrick

Excerpt from the eBook "IBM i Encryption with FieldProc - Protecting Data at Rest."

Encryption in FieldProc

It goes without saying that your FieldProc application will need to use an encryption library to perform encryption and decryption operations. IBM provides an encryption software library as a native part of the IBM i operating system. It is available to any customer or vendor who needs to implement encryption and decryption in their FieldProc programs.

Unfortunately the native IBM encryption library is very slow. This might not be noticeable when encrypting or decrypting a small amount of data. But batch operations can be negatively impacted. The advent of AES encryption on the Power8 processor has done little to mitigate the performance issue with encryption. IBM i customers and third party vendors of FieldProc solutions should use caution when implementing FieldProc using the native IBM i AES software libraries. They are undoubtedly accurate implementations of AES encryption, but suffer on the performance front.

Key Management

An encryption strategy is only as good as the key management strategy, and it is difficult to get key management right. For companies doing encryption the most common cause of an audit failure is an improper implementation of key management. Here are a few core concepts that govern a good key management strategy:

• Encryption keys are not stored on the same system as the sensitive data they protect.
• Security administrators of the key management solution should have no access to the sensitive data, and database administrators should have no access to encryption key management (Separation of Duties).
• On the IBM i system this means that security administrators such as QSECOFR and any user with All Object (*ALLOBJ) should not have access to data encryption keys or key encryption keys.
• More than one security administrator should authenticate before accessing and managing keys (Dual Control).
• All access to encryption keys should be logged and audited. This includes use of encryption keys as well as management of keys.
• Encryption keys should be mirrored/backed up in real time to match the organization’s standards for system availability.

Encryption Key Caching

Encryption keys are often used frequently when batch operations are performed on sensitive data. It is not unusual that a batch program would need to perform millions or tens of millions of encryption and decryption operations. While the retrieval of an encryption key from the key server may be very efficient, performance may suffer when keys need to be retrieved many times. This can be addressed through encryption key caching in the local environment.

Secure key caching should be performed in separate program modules such as a service program and should not be cached in user programs where they are more subject to discovery and loss. Any module caching an encryption key should have debugging options disabled and visibility removed. Secure key caching is critical for system performance and care should be taken to protect storage.

Encryption Key Rotation

Periodically changing the encryption keys (sometimes called “key rotation” or “key rollover”) is important
to the overall security of your protected data. Both data encryption keys (DEK) and key encryption keys (KEK) should be changed at appropriate intervals. The appropriate interval for changing keys depends on a number of variables including the amount of data the key protects and the sensitivity of that data, as well as other factors. This interval is called the cryptoperiod of the key and is defined by NIST in Special Publication 800-57 “Key Management Best Practices”. For most IBM i customers rotation of data encryption keys should occur once a year and rotation of the key encryption keys should occur no less than once every two years. 

Excerpt from the eBook "Encryption & Key Management for Microsoft SQL Server."

Microsoft SQL Server has become a ubiquitous storage mechanism for all types of digital assets. Protecting these data assets in SQL Server is a top priority for business executives, security specialists, and IT professionals.  The loss of sensitive data can be devastating to the organization and in some cases represents a catastrophic loss. There is no alternative to a digital existence and cybercriminals, political activists, and state actors have become more and more adept at stealing this information.  To properly protect this information, businesses are turning to encryption and key management.

Encryption

Encryption in the broadest sense means obscuring information to make it inaccessible to un- authorized access. But here we will use the term in its more precise and common use – the use of well accepted encryption algorithms based on mathematical proofs and which have been embodied and approved as international standards.

Many approaches to encryption do not meet minimal requirements for security and compliance. Our definition of encryption excludes:

• Homegrown methods developed by even experienced and talented programmers.
• Emerging encryption methods that are not yet widely accepted.
• Encryption methods that are widely accepted as secure, but which have not been adopted by standards organizations.
• Data substitution and masking methods not based on encryption.

An example of an encryption method that does meet our criteria would include the Advanced Encryption Standard (AES) which is sometimes knows as Rijndael, Triple Data Encryption Standard (3DES), RSA, and Elliptic Curve encryption methods.

In the context of protecting data in a SQL Server data- base, the most common encryption method protecting whole databases or an individual column in a table is AES. All key sizes of AES (128-bit, 192-bit, and 256-bit) are considered secure and are appropriate for protecting digital assets. Many organizations chose 256- bit AES for this purpose due to the larger key size and stronger security.

One major additional benefit of using an industry standard such as AES is that it meets many compliance requirements or recommendations for the use of industry standard encryption. This includes the PCI Data Security Standard (PCI-DSS), HIPAA, FFIEC, and the EU General Data Protection Regulation (EU GDPR).

Key Management

It is not possible to discuss an encryption strategy without discussing the protection of encryption keys. An encryption strategy is only as good as the method used to protect the encryption keys. Encryption algorithms such as AES and Triple DES are public and readily available to any attacker. The protection of the encryption key is the core to the security of the encrypted data. This is why security professionals consider the loss of the encryption key as equivalent to the loss of the digital assets. Once an attacker has the encryption key it is trivial to decrypt and steal the data.

Generating strong encryption keys and protecting them is harder that it might at first appear. The generation of strong encryption keys depends on the use of random number generation schemes, and modern computers do not excel at doing things randomly. Specialized software routines are needed to generate strong encryption keys. Encryption keys must also be securely stored away from the data they protect, and yet must be readily available to users and applications that are authorized to access the sensitive data. Authenticating that a user or application is authorized to an encryption key is a large focus of key management systems.

Over the years standards and best practices have emerged for encryption key management and these have been embodied in specialized security applications called Key Management Systems (KMS), or Enterprise Key Management (EKM) systems. The National Institute of Standards and Technology (NIST) has taken a lead in this area with the creation of Special Publication 800-57 entitled “Recommendation for Key Management”. In addition to this important NIST guidance, the organization publishes the Federal Information Processing Standard (FIPS) 140-2 “Security Requirements for Cryptographic Modules”. To serve the needs of organizations needing independent certification that a key management application meets this standard, NIST provides a validation program for FIPS 140-2 compliant systems. All professional key management systems have been validated to FIPS 140-2.

When protecting sensitive SQL Server data with encryption, look for these core principles of key management:

• Encryption keys are stored away from the data they protect, usually on specially designed security devices or dedicated virtual servers.
• Encryption keys are managed by individuals who do not have access to the data stored in the SQL Server database (Separation of Duties).
• Encryption key management requires more than one security administrator to authenticate before performing any critical work on keys (Dual control).
• Key retrieval requests from users and applications are authenticated using industry standard methods.
• Encryption management and key usage are logged in real time and logs are stored on secure log collection servers.
• Encryption key management systems have been validated to FIPS 140-2 and the Key Management Interoperability Protocol (KMIP).

These are just a few of the core requirements for deploying a professional key management solution to protect your SQL Server data.

For most people cryptography is a mysterious art conjured by magicians who speak an odd and unknowable language and who live in some remote and inaccessible deep forest occupied by unnamed and un-cataloged creatures. A land that perhaps Tolkien would know best. We wouldn’t know quite what to do if we met one of these folks.

But the fact is that we owe an enormous debt of gratitude to these mathematicians as the practical results of their work keep us safe every day. Some of them work in academic environments around the world, some work for large companies like IBM and Microsoft, some work for governmental agencies, and some are students. Cryptography (sometimes called Cryptology) is a branch of mathematics and encompasses a number of areas. Like any area of academic specialization some cryptographers are well known, and some are mostly invisible outside of their academic area of specialty. You may have heard of Bruce Schneier as he is quite well known through his writing, speaking engagements and testimony before committees of the US Congress.

You may not have heard of Phillip Rogaway.

Professor Rogaway has made significant contributions to cryptography and works with other cryptographers to advance the field. He holds a professorship at the University of California Davis, and positions in other academic institutions around the world.  It would be hard to overestimate the importance of his and his colleague’s work in making our modern world safe and workable.

I would like to call your attention to a talk Professor Rogaway gave at the Asiacrypt 2015 conference in Auckland, New Zealand a little over a year ago. It had nothing to do with cryptography, and yet it had everything to do with cryptography.

Phillip Rogaway made an elegant argument about the moral and ethical considerations about the work that cryptographers do. He directly addresses his colleagues and students entering the field and adds a plea that they take into account the moral and ethical uses of their work. While he is addressing a relatively small audience of cryptographers and security specialists, I believe that his message is relevant to every one of us who work at some level in this field including software engineers, security professionals, security auditors, cyber security specialists, and anyone else active in the security industry in any capacity. The paper that was the basis of his presentation is one of the most powerful that I’ve read in some time.

I encourage you to read it.

It is a wonderful read for anyone, and especially for those of us who work in the security industry. If I could I would certainly make this paper required reading for any student in a computer science course of study. Those of us who love building security solutions should fully understand the impacts of what we do. Others in the academic community have discussed the ethics and uses of cryptography, but Phillip Rogaway shines a bright light on this area better than anyone I know.

I don’t know Professor Rogaway and I’ve not had the pleasure of meeting him. But I recognize important moral work when I encounter it. If you work in the security industry in any capacity I hope you will take the time to give this paper a read.

Patrick

Phillip Rogaway’s web site

Phillip Rogaway’s paper

Excerpt from the eBook "IBM i Encryption with FieldProc - Protecting Data at Rest."

The performance of an encryption solution is one of the biggest concerns that an IBM i customer has when implementing FieldProc. There are many factors that can affect performance of a FieldProc application and it is wise to pay special attention to performance as you prepare to implement a solution. Let’s look at several factors that can affect performance.

AES 128-bit and AES 256-bit Performance

All key sizes for AES encryption (128-bit, 192-bit, and 256-bit) are considered secure for protecting all commercial sensitive data. Customers naturally wonder if the smaller key size of 128-bit encryption means better encryption performance when compared to 256-bit AES keys. In fact, the performance difference is much smaller than one might imagine. The smaller 128-bit key size uses 10 rounds during AES encryption, but the 256-bit AES keys use 14 rounds during AES encryption. The IBM i RISC processor optimizes cryptographic operations so the performance penalty for 256-bit AES encryption is very small. Considering that cybersecurity guidelines now recommend the use of 256-bit AES for protecting data in long-term storage, and for protecting against advances in quantum computing, you should always consider using 256-bit AES encryption for protecting IBM i sensitive data.

AES Encryption Software Performance

Encryption software libraries can vary greatly in performance even when using exactly the same methods and key sizes. Unfortunately the native IBM i AES encryption software library and APIs have a low performance profile and this can have a negative impact on your IBM i applications. Fortunately, there are high performance AES encryption libraries available from third parties that have a much better performance profile. The difference between the native IBM encryption libraries and third party libraries can be more than 100 times in processing speed. Use care when deploying an encryption solution to insure that the performance meets your minimum needs for processing time.

POWER8 On-Chip AES Encryption Performance

The new Power8 processor from IBM provides a hardware implementation of AES encryption to improve the performance of encryption. All new models of IBM i servers built with the POWER8 processor include this hardware implementation of AES encryption. In concept this is similar to the Intel processors which provide AES encryption through the AES-NI implementation.

While encryption performance has improved with the POWER8 processor, it is not a large improvement. Encryption speeds using the native IBM i APIs are about double the speed of the previous versions of the Power processor, but still greatly lag in performance compared to third party encryption libraries. It should be noted that this performance lag disappears when the IBM APIs are used to encryption very large blocks of information. For example, the AES implementation on the POWER8 processor can encrypt a megabyte of information at incredible speeds. Unfortunately this does not apply to the smaller blocks of data (credit card numbers, social security numbers, etc.) that are typically stored in DB2 database tables. It is likely that IBM i customers using iASP encryption will see a major performance bene t with the new POWER8 systems.

FieldProgram Program Performance

When FieldProc invokes a program to perform encryption or decryption it makes a dynamic all to a program executable. There is always a certain amount of overhead when making a dynamic call to an external program and this is true in FieldProc context, too. The more columns in a table that are under FieldProc control the more dynamic calls you will have to the FieldProc program as the FieldProc program is invoked independently for each column. It is important that the FieldProc program be properly optimized
for performance. Some key performance measures include:

• Minimized file I/O operations by the FieldProc program.
• Program modules are optimized on compilation.
• The program executable is optimized on compilation.
• Memory management is optimized for performance.
• Visibility of program objects is removed to improve performance.
• The FieldProc program is optimized for multi- threaded operation.
• Audit logging is optimized for performance.