Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

Microsoft SQL Server Encryption - An Introduction

Posted by Patrick Townsend on Feb 6, 2017 2:33:16 PM

In 2008 the Payment Card Industry Data Security Standard (PCI-DSS) was gaining serious traction and Microsoft released SQL Server 2008 with built-in support for encryption. This was no coincidence. In addition to the PCI standard which mandated encryption of credit card numbers, numerous states in the US had also adopted data breach notification laws with strong recommendations for encryption. The compliance environment was changing dramatically and the SQL Server group at Microsoft provided a path to meet those new compliance regulations. This was a prescient and crucially important enhancement for Microsoft customers - the security threats have increased over time and compliance regulations have become more stringent.

Encryption and key management for SQL Server In this multi-part series I want to talk about how Microsoft implemented encryption in SQL Server, how you can leverage this capability to achieve better security and compliance, and the critical issues involved in getting encryption right with SQL Server. I hope you will find this series helpful as you negotiate your SQL Server encryption projects.

Many Microsoft applications and services implement a “Provider” interface. This is the term that Microsoft uses to describe a standardardized, pluggable architecture for third party software companies to integrate and extend the capabilities of Microsoft solutions. With Provider architectures Microsoft enables a method for third parties to register their software to the Microsoft application, and the Microsoft application will then call that software as needed. The third party software must obey rules about the data interface and behavior of their applications. If done correctly the Provider interface provides powerful extensions to Microsoft applications.

Starting with SQL Server 2008 the database implements a Provider interface for encryption and key management. This is named the “Extensible Key Management” Provider interface, or the “EKM Provider”. EKM Provider software performs encryption and key management tasks as an extension to the SQL Server database. The EKM Provider architecture opened the door for third party key management vendors to extend encryption to include proper encryption key management.

From a high level point of view the EKM architecture looks like this:


Every version of SQL Server since 2008 has fully implemented the EKM Provider architecture. This has provided a stable and predictable interface for Microsoft customers and encryption key management vendors.

EKM Architecture - Column and Database Encryption
The EKM Provider architecture supports two different methods of database encryption:

  • Cell Level Encryption
  • Transparent Database Encryption

Cell level encryption is also known as column level encryption. As its name implies it encrypts data in a column in a table. When a new row is inserted into a table, or when a column in a row is updated, the SQL Server database calls the EKM Provider software to perform encryption. When a column is retrieved from the database through a SQL SELECT or other statement the EKM Provider software is called to perform decryption. The EKM Provider software is responsible for both encryption and key management activity. Implementing cell level encryption requires minor changes to the SQL column definition.

Transparent Database Encryption, or TDE, provides encryption for the entire database and associated log files. All tables and views in the database are fully encrypted. Data is encrypted and decrypted as information is inserted, updated, and retrieved by users and applications. As its name implies, transparent data encryption requires no changes to applications, SQL definitions, or queries. The database works seamlessly after encryption is enabled.

Transparent Data Encryption is the easiest of the two encryption methods to implement. In a following part of these series I will discuss when it makes sense to use TDE and when Cell Level Encryption is a better choice.

Activating the EKM Provider
After installing the EKM Provider software from a third party, the SQL Server database administrator uses the SQL Server management console to activate the EKM Provider and place the database or columns under encryption control. The activation of the EKM Provider software causes the database to be immediately encrypted and all further data operations on the database will invoke the EKM Provider software.

Microsoft EKM Provider for Locally Stored Encryption Keys
Recognizing that some SQL Server customers wanted to encrypt data but did not have the resources or time to implement a key management solution, Microsoft provided a built-in EKM Provider that performs encryption but which stores encryption keys locally in the SQL Server context. Understanding that this was not a security best practice, Microsoft recommends that customers use a proper encryption key management solution that separates encryption keys from the SQL Server database. That was good advice - locally stored encryption keys can be recovered by cyber criminals and the use of external key management systems provides better security and compliance.

EKM Provider Software
EKM Provider software is usually provided by your encryption key management vendor. This means that the features and functions of the EKM Provider software can vary a great deal from one vendor to another. Be sure that you fully understand the architecture and capabilities of the EKM Provider before you deploy SQL Server encryption.

SQL Server Versions That Support EKM
EKM Provider support is available in all Enterprise editions of SQL Server including Data Warehouse and Business Intelligence editions. EKM provider support is not available in Standard, Web, or Express editions of SQL Server.

In the following series I will go into more detail on the EKM Provider interface, transparent data encryption, cell level encryption, business continuity, compliance, and other topics.


Encryption and key management for SQL Server

Topics: Encryption, SQL Server

New York Department of Financial Services (NYDFS) and Encryption - 8 Things to Do Now

Posted by Patrick Townsend on Dec 12, 2016 10:27:38 AM

The New York Department of Financial Services (NYDFS) surprised the financial services industry by fast tracking new cybersecurity regulations in September of 2016. Due to go into effect in January of 2017 with a one-year transition period, it takes a very prescriptive approach to cybersecurity which includes a mandate to encrypt data at rest. The financial sector is broadly defined as banks, insurance companies, consumer lenders, money transmitters, and others. The law is formally known as 23 NYCRR 500 and you can get it here.

eBook The Encryption Guide There isn’t much wiggle room on the requirement for encrypting sensitive data. You can use compensating controls if you can show that encryption is “infeasible”. But I am not sure how you would show that. All modern database systems used by financial applications support encryption. It would be hard to imagine a financial database where encryption would not be feasible. Don’t plan on that being an excuse to delay encrypting data at rest!

The time frame is short for implementing the encryption mandate. One year seems like a long time, but it is extremely aggressive given the development backlog I see in most banks.

Here are some things you should start doing right now:

1) Inventory All of Your Financial Systems

This seems like a no-brainer, but you might be surprised how many organizations have no formal inventory of their IT systems that contain financial data. This is a top-of-the list item on any cybersecurity list of recommendations, so making or updating this list will have a lot of benefits.

2) Document Storage of All Sensitive Information (Non-Public Information, or NPI)

For each system in your inventory (see above) document every database and storage mechanism that stores NPI. For database systems identify all tables and columns that contain NPI. You will need this documentation to meet the NYDFS requirements, and it is a roadmap to meeting the encryption requirements.

3) Prioritize Your Encryption Projects

You won’t be able to do everything at once. Following all modern cybersecurity recommendations, prioritize the systems and applications that should be addressed using a risk model. Here are a few factors that can help you prioritize:

  • Sensitivity of data
  • Amount of data at risk
  • Exposure risk of the systems and data
  • Compliance risk
  • Operational impact of loss

It is OK to be practical about how you prioritize the systems, but avoid assigning a high priority to a system because it might be easiest. It is better to tackle the biggest risks first.

4) Establish Encryption Standards

Be careful which encryption algorithms you use to protect sensitive data. In the event of a loss you won’t want to be using home-grown or non-standard encryption. Protect data at rest with NIST compliant, 256-bit AES encryption. This will give you the most defensible encryption strategy and is readily available in all major operating systems such as Windows, Linux, and IBM enterprise systems.

5) Establish Key Management Standards

Protecting encryption keys is the most important part of your encryption strategy and the one area where many organizations fail. Encryption keys should be stored away from the encrypted financial data in a security device specifically designed for this task. There are a number of commercial key management systems to choose from. Be sure your system is FIPS 140-2 compliant and implements the industry standard Key Management Interoperability Protocol (KMIP).

Hint: Don’t fall into the project-killing trap of trying to find a key management system that can meet every key management need you have in the organization. The industry just isn’t there yet. Pick a small number of key management vendors with best-of-breed solutions.

With encryption standards well defined and an encryption key management strategy in hand you are ready to get started with your encryption projects.

6) Analyze Performance and Operational Impacts

Encryption will naturally involve some performance and operational impacts. Encryption is a CPU intensive task, so plan on doing some performance analysis of your application in real-world scenarios. If you don’t have test environments that support this analysis, get started now to create them. They will be invaluable as you move forward. Modern encryption is highly optimized, and you can implement encryption without degrading the user experience. Just be prepared to do this analysis before you go live.

There are also operational impacts when you start encrypting data. Your backups may take a bit more storage and take longer to execute. So be sure to analyze this as a part of your proof-of-concept. Encrypted data does not compress as well as unencrypted data and this is the main cause of operational slow-downs. For most organizations this will not be a major impact, but be sure to test this before you deploy encryption.

8) Get Started

Oddly (to me at least) many organizations just fail to start their encryption projects even when they have done the initial planning. A lack of commitment by senior management, lack of IT resources, competing business objectives, and other barriers can delay a project. Don’t let your organization fall into this trap. Do your first project, get it into production, and analyze the project to determine how to do it better as you move forward.

Fortunately we have a lot of resources available to us today that were not available 10 years ago. Good encryption solutions are available and affordable for traditional on-premise environments, for VMware infrastructure, and for cloud applications.

You can meet the NYDFS requirements and timelines if you start now. But don’t put this one off.




New York Department of Financial Services:



Harvard Law School analysis of NYDFS:


The Encryption Guide eBook


Topics: Compliance, Encryption

Dangers of Encryption on the IBM i (AS/400, iSeries): Avoid These Pitfalls

Posted by Patrick Townsend on Nov 14, 2016 8:35:13 AM

IBM has done a good job of implementing security from the ground up on the IBM i platform. But that doesn’t mean that it is immune from data breaches. All of the PCs and servers on your network with the IBM i server are potential attack points for a data breach. And make no mistake, cyber criminals know that the IBM i server is a rich target. Implementing encryption in IBM i DB2 is an essential part of a defense in depth strategy. But there are lots of pitfalls to avoid. Let’s take a look at some of them (I am shamelessly plugging our Alliance AES/400 solution, too):

Key Management for IBM i - Audit Failures Locally Stored Encryption Keys and Key Management

One of the surest ways to defeat your encryption strategy is to store encryption keys on the same system that stores sensitive data. The IBM i server is no exception. Compliance regulations and security best practices require that you store encryption keys away from the IBM i server in an encryption key vault designed for this purpose. Why is this a security best practice? Cybercriminals are often able to achieve privilege escalation on a compromised IBM i server and then get access to locally stored keys. Storing encryption keys off of the IBM i server makes the compromise of the sensitive data much harder.

How Townsend Security Can Help

The Townsend Security Alliance AES/400 product integrates seamlessly with Townsend Security's Alliance Key Manager solution for protection of encryption keys and key management best practices. Alliance Key Manager stores encryption keys in a hardware security module or VMware instance that is attached to the IBM i server by a secure, authenticated TLS connection. As a FIPS 140-2 compliant key management solution, Alliance AES/400 with Alliance Key Manager solves the key management problem!

High Availability and Key Mirroring

Encryption key management is a part of your critical infrastructure. The loss of an encryption key means the loss of your data! Your encryption key management solution should implement real-time key mirroring and real-time security policy mirroring. In the event the key manager is unavailable due to a hardware or network failure, the failover to a secondary key server should be automatic without business interruption. A key management solution based on the IBM i master key facility cannot achieve real-time mirroring and protection from these failures.

How Townsend Security Can Help

Alliance Key Manager implements real-time key mirroring to one or more backup key servers. The mirroring implementation is active-active meaning that any changes you make to keys or access policies on the secondary server will be mirrored to the production server when it comes back online. This perfectly matches your IBM i high availability failover strategy if you use MIMIX, iTera, Vision, or IBM DataMirror.

Encryption and Insider Threats

Insider threats include both intentional and unintentional access to and loss of sensitive information. Unintentional losses of data represents the largest insider threat. Accidentally copying data to a PC or development environment can lead to a reportable data breach event. This is especially true when access controls to sensitive data are only controlled by native IBM i object level security. You should certainly use native IBM i security mechanisms, but access to decrypted sensitive data should also be controlled using a “whitelist” approach. This will help minimize the intentional and unintentional access by security administrators. Note that it is not only the security profile QSECOFR that has all access to sensitive data: all users with All Object (*ALLOBJ) authority or who adopt this level of authority through a group profile or supplemental group are at risk for intentional or unintentional loss of sensitive data.

How Townsend Security Can Help

Alliance AES/400 implements a whitelist approach for controlled access to decrypted sensitive data. All configuration changes to security policies are logged to the IBM security audit journal QAUDJRN. You can achieve effective Separation of Duties between managers of the encryption keys and security administrators on the IBM i platform.

Poorly Performing Encryption Libraries

Encryption can also present an operational risk to IBM i customers. In order to meet service level expectations of end users encryption and decryption operations must be efficient. Unfortunately for IBM i customers the native AES encryption software libraries provided in the operating system may not provide an adequate level of performance. Even with the new IBM i POWER8 servers with on-chip encryption, the performance of AES encryption and decryption tasks is poor. It is important to assess the size of your protected databases and the nature of batch operations that require access to unencrypted data in order to avoid negative impacts to both interactive and batch applications.

How Townsend Security Can Help

Alliance AES/400 uses the Townsend Security NIST-validated AES encryption library for encryption and decryption tasks. This optimized AES encryption library is more than 100x faster that native IBM i encryption libraries on POWER7 processors, and more than 50x faster on POWER8 processors.

Encrypted Indexes

Many IBM i customers are surprised to learn that their RPG applications will not work correctly with DB2 FieldProc for encrypted indexes (key fields). FieldProc is IBM’s automatic column level encryption feature implemented at the DB2 database level. FieldProc is attractive to IBM i customers because it does not require modifications to applications. While native SQL applications can easily handle encrypted indexes, RPG applications do not use the native SQL Query Engine (SQE) and will not work properly with encrypted indexes. Most IBM i customers exclusively use RPG or have a mix of RPG and SQL applications. The issue with RPG and encrypted indexes represents a major roadblock to encryption. Be sure that your encryption strategy can support encrypted indexes, or be prepared to modernize RPG applications to use native the SQL Query Engine.

How Townsend Security Can Help

Townsend Security tackled the problem of encrypted indexes and offers a solution to the RPG challenge through its Open Access for RPG SQL library. Changing one line of code in your RPG application can automatically use the native SQL Query Engine for database access. This eliminates the challenges of encrypted indexes with FieldProc encryption.

Data Masking

Compliance regulations such as PCI Data Security Standard (PCI-DSS) and security best practices require that we only allow authorized users access to fully decrypted sensitive data. But other users must have access to our database applications. This means that intelligent data masking should be built into your IBM i applications. As noted above, data masking should be based on a whitelist approach and not purely based on object or database level authority. You should have the ability to define masking rules (mask all but the last 4 characters, etc.) and you should be able to define a default masking rule that applies to all unauthorized users. While Row and Column Access Controls (RCAC) can provide some data masking capability, you must manage individual user level authorities to implement this control.

How Townsend Security Can Help

Alliance AES/400 fully implements data masking using a whitelist approach and provides protections from users with All Object (*ALLOBJ) or Security Administrator (*SECADM) privileges. Data is masked in the internal decryption routines and fully exposed data is never visible in the application program.

System Audit Logs

No security policy or solution can be effective on a stand-alone basis and this includes encryption and key management. A good encryption and key management strategy involves monitoring all access to sensitive data, monitoring changes to encryption and key management configurations, monitoring all use of encryption keys, and storing audit logs for future forensic reference. The use of Security Information and Event Management (SIEM) solutions is highly recommended as a part of your monitoring and alerting strategy. Be sure that all access to encryption and encryption keys is fully audited and logged.

How Townsend Security Can Help

Alliance AES/400 and Alliance Key Manager implement system logging and audit for all aspects of administration, configuration and use. Alliance Key Manager implements full logging of all aspects of key management and the server it runs on, and transmits logs to a SIEM solution in real time. Alliance AES/400 fully logs all administrative operations and decryption tasks to the IBM i security audit journal QAUDJRN. The optional Alliance LogAgent solution transmits these logs as well as all IBM i security events to a SIEM solution or log collection server.

Encryption and key management don’t have to feel dangerous or scary! I hope the above points about encryption and key management for the IBM i help you develop a roadmap for successful (and safe!) encryption.


Key Management for IBM i - Sources of Audit Failures

Topics: Encryption, Key Management, IBM i

Encryption & Key Management for the IBM i

Posted by Luke Probasco on Jul 25, 2016 10:38:04 AM

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.

IBM i Encryption with FieldProc 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. 

IBM i Encryption with FieldProc

Topics: Encryption, IBM i, FIELDPROC

Encryption & Key Management for SQL Server

Posted by Luke Probasco on Jul 22, 2016 3:27:11 PM

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 and key management for SQL Server 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.

Encryption and key management for SQL Server


Topics: Encryption, SQL Server

Top 10 Signs Your Encryption Strategy May Have a Problem

Posted by Patrick Townsend on Jul 22, 2016 8:44:12 AM

With apologies to David Letterman, the category today is: Signs Your Encryption Strategy May Have a Problem.  Here they are, your Top 10!


Number 10:

Your decryption fails when you can’t remember where you placed the Annie Oakley decoder ring.

Number 9:

The photos of you in your unicorn costume at Comic-Con, yes, THOSE PHOTOS, are being posted on twitter by anonymous.

Number 8:

Managing encryption keys involves sticky notes on your desk and computer.

Number 7:

When you tell your CEO that the company has poor key management, and he fires you for being disrespectful.

Number 6:

Your encryption strategy is the ransomware that the CEO accidentally downloaded.

Number 5:

When you find out that Pig Latin is not a viable encryption strategy.

Number 4:

Your System Administrator installs new software from a compact disc that has "Totally Legit" written on it in sharpie.

Number 3:

Your passcode is 1234.

Number 2:

Your server password list is projected on a big screen as an example during a presentation at the RSA security conference.

And LAST but not LEAST - Number 1:

This is what your encryption key manager looks like:

password book

And those are the Top 10 signs your encryption strategy may have a problem !!!


The Encryption Guide eBook

Topics: Encryption

IBM, Quantum Computing and Encryption

Posted by Patrick Townsend on Jul 18, 2016 11:20:47 AM

IBM made some news recently when they announced availability of Quantum computing capability via the IBM Cloud platform. You can find more information on their website at IBM.com and the press release is here.

eBook The Encryption Guide Of course, organizations that protect data with encryption are asking if Quantum computing will break their encryption! It is a good question, but first a little explanation. Quantum computing is not the same as Quantum cryptography (quantum encryption). We are obviously in the early days of practical implementations of Quantum computing, but Quantum encryption is not yet practical and there are many problems to be resolved. So don’t be confused when people talk about Quantum computing. The impact on encryption is not dire right now, but it is good to stay aware of the technical progress of Quantum computing.

Recognizing that US government agencies needed some guidance on this topic, the NSA released an FAQ about Quantum computing and guidelines for national security systems (NSS). You can find that guidance here.

I know that many of you are skeptical about NSA guidance. The NSA has probably earned that skepticism based on its poor behavior around the EC-DBRG debacle as well as other activities. If it is any comfort I believe that the National Institute of Standards and Technology (NIST) will also be taking up this issue and involve the global cryptographic community. When that work is finished I believe they will release independent guidance around this question, too. But until then I think the NSA guidance is pretty good.

Because data is often stored for long periods of time, the NSA guidance attempts to insure data protection for several decades in the future. So what are the recommendations?

The encryption most often used for storage is AES. If you have a concern about long term storage the NSA recommends the use of 256-bit AES encryption. The implication is that 256-bit AES encryption will resist the advances of Quantum computing and keep your data safe for a long time to come. Remember that the concern is for data security many years in the future, so if you are using 128-bit AES encryption to protect data today you probably don’t need to panic. But as you move forward and replace backup and storage solutions I would recommend that you use 256-bit AES encryption for data protection.

Protecting data in motion is more affected by the strength of the asymmetric keys that are used to negotiate end-to-end connections. While 2048-bit RSA keys are now considered strong encryption, the NSA recommends moving to 3072-bit or larger RSA keys. Elliptic curve should move ECDH with NIST P-384, and Diffie Hellman should move to 3072-bit keys or larger. Again, there is no need to panic if you are using smaller keys, but if you are concerned about the capture of secure internet sessions and the security of those sessions some years from now you should move to the larger key sizes soon. Before you make any changes please be aware that larger RSA key sizes will impose a performance penalty. Look before you leap!

I believe that for the vast majority of non-governmental organizations the current recommended key sizes are adequate and you should not be overly concerned about the impacts of Quantum computing. The NSA guidance and the forthcoming NIST guidance will give us a good consensus on the recommendations for encryption key sizes.


The Encryption Guide eBook

Topics: Encryption

Phillip Rogaway Said Something Important

Posted by Patrick Townsend on Jul 14, 2016 8:44:00 AM

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.

data-encryption.jpgBut 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.



Phillip Rogaway’s web site

Phillip Rogaway’s paper

The Encryption Guide eBook

Topics: Encryption

Encryption Performance on the IBM i

Posted by Luke Probasco on Jul 12, 2016 11:11:00 AM

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

IBM i Encryption with FieldProc 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. 

It is important that the FieldProc application be properly optimized as it may be invoked many times during a typical interactive or batch request.

FieldProc for Multiple Columns in a Table

It is likely that you will need to protect multiple columns in a table. For example, in a medical setting a table might contain the following information for a patient:

  • Name
  • Date of birth
  • Address
  • Social security number
  • Email address
  • Etc.
In this case you will be protecting multiple columns in a single table. This is fully supported by FieldProc and is very common in FieldProc implementations. When FieldProc programs are properly optimized for performance you should find that the extra performance impacts per column are not excessive. Thanks to the re-entrant model of the IBM i operating system the protection of multiple columns has a smaller performance impact. Encrypting two columns is NOT twice the performance impact as encryption one column.

Key Management Performance Impacts

As mentioned above your FieldProc encryption solution should implement good encryption key management practices. It is important that the key management interface impose little performance penalty. This means that the FieldProc application should use intelligent and secure key caching to minimize the number of key retrieval operations that must be performed. Additionally keys should not be exposed in user applications, but should be protected in separate modules. When implemented properly good key management will impose extremely little performance impact.   

Audit Logging Performance

One common feature of FieldProc applications is the ability to collect audit information about user activity. This might include collecting information about which users accessed decrypted information, etc. Audit logging will always extract a performance price. If you need to collect audit logs of FieldProc activity be sure to measure the performance impact of audit log collection in your own environment.

IBM i Encryption with FieldProc

Topics: Encryption, FIELDPROC

Key Management: The Hardest Part of Encryption

Posted by Luke Probasco on Jun 3, 2016 7:19:00 AM

Excerpt from the eBook "2016 Encryption Key Management: Industry Perspectives and Trends." 

2016 Encryption Key Management Industry Perspectives and Trends eBook While organizations are now committed to implementing encryption, they are still struggling with getting encryption key management right. With all major operating systems, cloud platforms, and virtualization products now supporting encryption, it is relatively easy to make the decision to activate encryption to protect sensitive data. But an encryption strategy is only as good as the method used to protect encryption keys. Most audit failures for customers already using encryption involve the improper storage and protection of encryption keys.

Ignorance and fear are the driving reasons for this core security failure. Many IT professionals are still not versed in best practices for encryption key management, and IT managers fear that the loss of encryption keys or the failure of access to a key manager will render their data unusable. This leads to insecure storage of encryption keys in application code, unprotected files on the data server, and poor protection of locally stored keys.

Most encryption key management solutions have evolved over the last decade to provide unparalleled reliability and redundancy. This has largely removed the risk of key loss in critical business databases and applications. But the concern persists and inhibits the adoption of defensible key management strategies.

Take Aways

  • Protect encryption keys with single-purpose key management security solutions.
  • Never store encryption keys on the same server that houses sensitive data.
  • Only deploy encryption key management solutions that are based on FIPS 140-2 compliant technology.
  • Only deploy encryption key management solutions that implement the KMIP industry standard for interoperability.
  • Avoid cloud service provider key management services where key management and key custody are not fully under your control.

Cloud Migration and Key Management Challenges

Cloud migration continues to a be a high priority for organizations large and small. The benefits for migrating to the cloud are clear. Reduction in cost for computing power and storage, leverage of converged infrastructure, reduction of IT administrative costs, on-demand
scalability, and many other benefits will continue the rapid migration to cloud platforms. As cloud platforms such as Amazon Web Services (AWS), Microsoft Azure, Google App and Compute Engine, and IBM SoftLayer mature we can expect the pace of cloud migration to accelerate.

While cloud service providers are providing some encryption key management capabilities, this area will continue to be a challenge. The question of who has control of the encryption keys (key custody) and the shared resources of multi-tenant cloud service providers will continue to be headaches for organizations migrating to the cloud. The ability to exclusively manage encryption keys and deny access to the cloud service provider or any other third-party will be crucial to a good cloud key management strategy and end-customer trust. The attempt by governments and law enforcement agencies to access encrypted data through access to encryption keys will make this issue far more difficult moving forward.

Unfortunately most cloud service providers have not adopted common industry standards for encryption key management. This results in the inability of customers to easily migrate from one cloud platform to another resulting in cloud service provider lock-in. Given the rapid evolution of cloud computing and the infancy of cloud computing, customers will have to work hard to avoid this lock-in, especially in the area of encryption key management. This is unlikely to change in the near future.

Take Aways

  • Avoid hardware-only encryption key management solutions prior to cloud migration. Make sure your key management vendor has a clear strategy for cloud migration.
  • Ensure that your encryption key management solution runs natively in cloud, virtual and hardware platforms.
  • Ensure that your encryption key management solution provides you with exclusive management of and access to encryption keys. Neither your cloud service provider nor your encryption key management vendor should have administrative or management access to keys. Backdoor access through common keys or key management code is unacceptable.
  • Avoid cloud service provider lock-in to proprietary key management services. The cloud is still in its infancy and retaining your ability to choose and migrate between cloud platforms is important.

Topics: Encryption, Encryption Key Management

Subscribe to Email Updates

Posts by Topic

see all