I found the data breach of Epsilon just shocking for several reasons:

First, the scope of the breach was astounding. About 2,500 companies are using Epsilon for email communications with their customers, and some of these companies are quite large. Thus the number of email addresses exposed was gigantic. You really have to wonder why those email addresses weren’t encrypted. Anyone would see those email addresses as a high value target. And email addresses are Personally Identifiable Information (PII), after all.

Second, you have to wonder why really large companies trusted Epsilon with their customer information without insisting on good data protection practices.  What were they thinking? When you hand over your data to an outside company, you aren’t off the hook if there is a data loss.  It wasn’t Epsilon who had to send emails and letters to customers. The originating companies bear the cost of that effort, and the business damage that follows.

Third, the loss of an email address is not trivial. It’s true that email addresses are more public than many bits of personal information we have. But email addresses are often used as account identifiers for on-line services. If I have your account ID it is a lot easier to attack your password credential. People are amazing lax about creating strong passwords. So the loss of emails provides one more weak link in the chain of security for individuals.

Then there are the phishing attacks. If I have your email address it is a lot easier to send you an infected PDF file. I just look on your company’s web site or Facebook page and find the name of your CEO. Then I send you an email with the CEO’s name and an infected PDF. Perhaps I name the PDF “Look at these terrible results!.pdf”. You are probably going to jump to open that one!  So now I have invaded your internal network.

You can see how this can really escalate to bad news for you and your organization.

The lesson for any organization is to do some due diligence with your service providers. Be sure they are protecting your information with the same level of care that you do. After all, you are on the hook if they lose your data.  For more information, download our white paper titled AES encryption and Related Concepts.

Encryption and tokenization are the two leading technologies used to protect sensitive data from loss and subsequent breach notification and legal liability. Organizations who try to meet compliance regulations struggle to understand when to use strong encryption and when to use tokenization to protect information. Many organizations will find both technologies helpful in different places in their IT infrastructure.

Encryption protects data by obscuring it with the use of an approved encryption algorithm such as AES and a secret key. Once encrypted, the original value can only be recovered if you have the secret key. The use of strong encryption keys makes it impossible, from a practical point of view, to guess the key and recover the data. Almost all compliance regulations provide a safe harbor from breach notification if sensitive data is encrypted.

Encryption - Protecting Sensitive Data Where It Lives

Encryption is a mature technology with a recognized body of standards, independent certification of vendor technologies, and it undergoes continual scrutiny by the professional cryptographic community. Organizations that deploy professional encryption solutions that have been independently certified (NIST certification) enjoy a high level of confidence in the protection of their data assets.

Tokenization - Protecting Sensitive Data with Subsitution

Tokenization works by substituting a surrogate value for the original sensitive data. This surrogate value is called a “token”. The token value does not contain sensitive information, it replaces it, maintaining the original value.  There is one and only one token value for any given original value. For example, a credit card number 4111-1111-1111-1111 might be assigned the token value of 1823-5877-9043-1002. Once this token is assigned it will always be used when the original value would have been used.

Combining Encryption and Tokenization

For most organizations there will be appropriate uses for both encryption and tokenization. Encryption will be the right solution for one set of applications and databases, and tokenization will be the right solution for others.  The appropriate technology will be decided by each organization’s technical, compliance, and end-user staff working together.

In order to ease the development and compliance burden, organizations may wish to source encryption and tokenization solutions from the same vendor. There are many overlapping technologies in both encryption and tokenization, and you will probably want a common approach to both.

If you would like to learn more about tokenization, we recently presented a webinar titled "Tokenization & Compliance: 5 Ways to Reduce Costs and Increase Security." 

The other night I went to my very first WLC meeting.  WLC is apart of United Way, it stands for Women's Leadership Council.  WLC’s mission is to positively impact the lives of women in our community by promoting self sufficiency and financial stability through philanthropy and community service.

We went around the table and introduced ourselves.  There were many different job titles named;  financial advisor, real estate consultant, partner sales rep, and several others.  After we broke the ice (and secretly judged one another), we touched on all the subjects that women usually talk about, our children, significant others (what they are and are not doing), work and all the other stresses in our lives.   One lady suggested we do something that she does with all of her clients to help get to know them better and asked us, “What is your magic? What is it that sets you apart from everyone else in this world?”  
   
Well shoot!  What is my magic?  And for that matter, what is Townsend Security’s Magic - what sets us apart from the competition?

Our mission at Townsend Security is to provide our customers peace of mind when it comes to data privacy.  We help them do business securely and provide their customers peace of mind.  The way we deliver peace of mind is our magic, it is what sets us apart from any other encryption and key management company.  Our magic.... drum roll please.... is a combination of innovation, experience and our commitment to be known as more than just a data privacy company.  

Our independently certified solutions are developed by experts. The team at Townsend is well-known and well-respected in the industry. We understand the issues around data privacy and compliance and use that knowledge to create and support our solutions. We believe we should be the experts in data privacy so our customers can be the experts in their own industries. No one wakes up and says they want to start an encryption project and no project is the same - so when the time comes we are ready to listen to the problem that needs to be solved and deliver the right solution

In addition to data privacy, Townsend Security is locally known for its commitment to the community.  We are a proud supporter of the United Way and many other local non-profits.  In fact, we were just named the "2011 Corporate Supporter of the Year for Small Busineses" by the Thurston County chapter of United Way.  It is great to work at a company that not only says they want to make their community better - they actually do it and encourage all of its employees to do the same, this is how I became involved with the WLC, which gets back on track about the question posed to myself that night.   My magic, well.. it is everything WLC stands for a hard working young woman, who is graduating from college, raising a small child and doing it all with a positive attitude.  

The phone is ringing, so back to work I go. Time to share more of that Townsend magic (and my own) with one of our customers.  And if they haven’t read this blog post yet, I’ll send it their way.  We want our customers and our community to know how seriously we take our commitment to providing peace of mind in the solutions we sell and in the service we provide.  We know that everyone has their own magic and brings something unique to the table - let us know what yours is.

Pretty Good Privacy (PGP) is the de facto standard for encrypted file exchange among the world’s largest financial, medical, industrial, and services companies. Based on open standards and tested by time, PGP has won the trust of governments and private enterprises to protect their sensitive data.  Here are the six key things to know about PGP encryption for your IBM i and IBM z platforms, and how to discuss them with your technology providers:

1) Always encrypt and decrypt sensitive data on the platform where it is created. This is the only way to satisfy regulatory audit and privacy notification requirements.

Moving data to a PC for encryption and decryption tasks greatly increases the chances of loss and puts your most sensitive data at risk.  In order not to defeat your data security goals it is important to encrypt and decrypt data directly on the IBM i or IBM z.

2) The best PGP encryption solutions manage PGP keys directly on the IBM i or IBM z without the need for an external PC system, or key generation on a PC.

Using a PC to generate or manage PGP keys exposes the keys on the most vulnerable system. The loss of PGP keys may trigger expensive and time-consuming privacy notification requirements and force the change of PGP keys with all of your trading partners.

3) The best data security solutions will provide you with IBM i and IBM z automation tools that help minimize additional programming and meet your integration requirements.

Most Enterprise customers find that the cost of the software for an encryption solution is small compared to the cost of integrating the solution into their business applications. Data must be extracted from business applications, encrypted using PGP, transmitted to a trading partner, archived for future access, and tracked for regulatory audit. When receiving an encrypted file from a trading partner the file must be decrypted, transferred to an IBM i or IBM z library, and processed into the business application. All of these operations have to be automated to avoid expensive and time-consuming manual intervention.

4) PGP is part of a comprehensive data security plan.

PGP encryption is ideal for exchanging data with trading partners, banks, insurance companies, benefits providers, and many other external partners. It’s ability to run on any computing platform makes it ideal for this type of secure data exchange.

5) PGP helps meet data privacy compliance regulations.

Even if your company is not directly subject to PCI and other similar regulations, you will soon find that your customers who are subject to these laws will require that you be in compliance, too. As the financial auditing profession matures, auditors realize that their customers cannot meet regulatory requirements unless their suppliers meet these requirements.

6) Choose the trusted leader in data security.

When PGP Corporation selected a partner to bring PGP version 9 to the IBM i, POWER Linux, and IBM System z platforms, they selected Townsend Security as their exclusive partner. PGP Corporation’s knowledge of Townsend’s history with PGP on the IBM i and IBM z platforms made Townsend Security the natural choice.

Click the button below to download a free trial of PGP for the IBM i or IBM z from Townsend Security.

Emerging Data Privacy Regulations

Organizations need to comply with an increasing number of data privacy regulations.  In addition to regulations such as PCI, HIPAA/HITECH, GLBA/FFIEC, and Sarbanes-Oxley, states are passing their own privacy laws.  For example, Massachusetts says that if you are doing business with anyone in their state, you must comply with their privacy law – even if your business is located across the country.  NIST-certified encryption and key management can help meet these emerging regulations.

I recently sat down with Patrick to discuss the emerging data privacy regulations - as well as how to meet them and what it is like to have an audit. 

There are lots of different data privacy regulations for people dealing with sensitive information.  Can you speak a little about each one?

You are right.  There are a lot of regulations and companies are finding themselves falling under more than just one.  Probably the one that most people know about is the PCI Data Security Standards (PCI DSS).  Any organization that accepts credit cards for payment falls under these regulations.  In the medical segment we have the HIPAA and HITECH Act, which sets the standards for protecting patient information.  In the banking and financial area we have the GLBA and FFIEC regulations which cover a broad set of financial institutions.  FERPA is for educational institutions.  Sarbanes-Oxley (SOX) covers any publicly traded company.  Finally, we have state privacy laws on the books and there are about 44 or 45 of them.  So you are right, there are a lot of different privacy regulations and there are over-lapping and different requirements for each regulation.

So, an organization can be faced with several different compliance regulations, is there any common solution?

You need to be aware of each one, though there are some overlapping definitions of what constitutes Personally Identifiable Information (PII).  It is important to follow proper encryption and key management best practices and make sure your solutions are NIST certified.  State Privacy Laws are starting to follow PCI guidance.  It is important to note that State Privacy Laws are now starting to extend beyond the boundaries of the state.

Do any of these regulations have any real “teeth”?

Oh, yes!  A data breach can have lasting financial and business impacts.  Just ask the companies who have had major data breaches.  One credible study by the Ponemon Institute estimates that TJ Maxx may eventually spend a total of about 9 billion dollars (yes, that’s billion with a “B”) as a result of their data breach.  There have been numerous fines levied against merchants, medical providers, and businesses related to data security breaches.  There are real financial penalties for these breaches.

Less well known is the fact that an embarrassing data security breach can sink your business.  If a big part of your business is based on Internet sales, for example, you can find your business disappearing in the event you have a data breach.

What is the process of undergoing an audit like?

Don’t panic.  It can be painful, but in most cases and audit involves a routine set of questions.  You can actually prepare for that experience.  It is good to know the configuration of your network and where things stand in terms of data protection.  Having good documentation on your policies, procedures, your network, and your business applications is going to be very helpful in an audit.  Also, you should see your auditor as an important partner in compliance.  A good relationship with an auditor will help get you through the process.  You can see your auditor as someone who can really advise you on best practices for securing data.

Also, your software supplier can be an important partner.  For example, we offer a lot of questions about compliance regulations and best practices when we work with our customers and prospective customers – trying to get them educated on what really is best practice.

Are there any emerging regulations that our listeners should be aware of?

Congress is working on a Federal Privacy law that would replace the 44 or 45 state privacy regulations. Businesses struggle to keep up with the differences between all of the state laws, and there is business support for passing a federal law. A version has passed the House of Representatives, and there are two or three versions pending in the Senate. These will have to get consolidated into a single law, and then rationalized with the House bill. But eventually I think this will happen.

I think we can make some predictions about how a new federal law will affect businesses. We already have a template in the HITECH Act of 2009. I suspect that the FTC or some other federal agency will be tasked with defining the data security regulations. It is highly likely that the National Institute of Standards and Technology (NIST) will be the basis for standards and certification of solutions. Then there will be published rules and guidelines on how to implement data protection.

If I am right about this, it will prompt businesses to be sure that their data protection solutions meet NIST standards. And I don’t mean sorta, kinda, maybe. You need to find solutions are NIST certified to FIPS-140-2 or similar standards with the paper certificates to prove it.

Download a 30-day evaluation of NIST-certified AES database encryption from Townsend Security

The Importance of NIST Certification for AES Encryption

Download a Free Trial Now

All Encryption is Not Created Equal

The National Institute of Standards and Technology (NIST) defines the standard for AES encryption, and provides a rigorous testing process for software vendors. The certification process is carried out by independent testing labs who report the results to NIST for validation.  The AES certification process tests every aspect of encryption and involves millions of encryption and decryption operations. Only the most dedicated security vendors are able to pass the tests and achieve NIST certification.  Townsend Security has achieved AES Validation for all key sizes and modes of operation, on every major Enterprise platform. 

How important is NIST validation?

Steve Tenore, a Senior IBM i Consultant for Staples, says "Staples wouldn’t even consider a vendor solution that didn’t have NIST certification. The fact that Townsend Security has NIST certified solutions on the major Enterprise server platform was a big plus."

Need encryption done right?  Insist on NIST.

In a study of the certification program, NIST found nearly 50 percent of software vendors had errors in their encryption solutions. It isn’t easy to get encryption right. A certificate of validation from NIST is your assurance that AES encryption does what it is supposed to do. Every time.

Certification Means Stronger Encryption

NIST certification is your assurance that a vendor’s AES encryption solution implements data encryption the right way. There are many ways to use encryption and a wide variety of modes of encryption. Improperly implemented solutions may work for one type of task, but fail under different application requirements. All software vendors claim they implement strong encryption. Can they prove it? Ask them for their NIST certification.

Certification Means Reliability

The NIST testing process is designed to exercise a vendor’s encryption solution under stress conditions. Large numbers of repeated encryptions are performed with the output of one encryption used as input for the next encryption. Failures in memory management or reliability will be exposed in the testing process. Encryption software may work without errors for 100 or 1,000 encryptions, but will it work on 1 million encryptions? How about 100 million encryptions?

No one wants the unpleasant experience of a system failure due to unreliable software. NIST certification helps provide some assurance of a reliable implementation. 

Download a free trial of our AES Encryption (available for IBM i, IBM z, Windows, Linux, and UNIX) and be guaranteed that you are using the most secure and best performing encryption available.

5 Commonly Asked Questions About Data Privacy

The job to protect sensitive data often falls in the hands of IT security administrators and their teams because of their technical expertise. We feel data protection is everyone's responsibility because every employee has an invested interest in maintaining their organization's good reputation with customers and partners.

We have compiled questions from discussions over the years with  customers and prospects to help people understand the basics of data privacy and why responsibility of maintaining data integrity goes beyond the IT department.  In addition to this list, we have produced a podcast with more information - download it here.

1. What constitutes personal information that we have to protect and how do businesses protect this information?

The first things people think of are credit card or social security numbers.  However, other pieces of information are equally as important.  Think about the things your bank asks you when you call them to talk about your account. Can you verify your phone number? The last four digits of your social security number? Your birthdate? Maiden name? These pieces of information can be used to commit fraud. 

The banks are using that information to identify you. And the fraudsters will use that information to impersonate you. The technical term for this kind of information is Personally Identifiable Information, or PII.

Businesses can protect data with a few different techniques involving third-party software solutions and implementing internal policies around who has access to data.

Vendor solutions can provide the ability to control who has access to data inside the company and prevent potential hackers from gaining access to your network.   Companies can also use vendor solutions to encrypt their data. Encryption is a process that takes sensitive information and runs it through a scrambling process. Once encrypted, your data can only be deciphered with a special key.  The data is useless to the person that attempts to steal it, unless they they have the key.

2. We’ve been hearing a lot about encryption and key management. How do they relate to each other?

They go together, they are complementary technologies. In addition to the raw credit card number, another very important input to the encryption is the secret key.  Without the key, no one can read the encrypted data. Many people think that an encryption algorithm itself is a secret mechanism, but that’s not the case. Encryption is well understood, there are standards for it and they’re readily available.  The secret that prevents malicious users from stealing data is the encryption key.

At home, the key to your front door is what protects you. Companies that use encryption have to create a key that is unique and strong, and then protect it to ensure it doesn’t get into the wild. Anyone who has the key can get the data. In the real world of protecting data with encryption, the encryption key is what users are taking care to protect.

3. What happens when the encryption is not done correctly?

There are many ways that encryption can be done incorrectly or poorly. We see that particularly around the area of encryption key management. One big mistake many people make is storing an encryption key on the same platform where the data are stored. Sometimes you hear the term integrated key management to describe this practice. Even if you lock down the database, keeping it on the same partition as your data leaves it readily accessible for potential cracking.

Other examples are using nonstandard or proprietary encryption. It’s important that a company buying encryption technology should vet their vendors carefully. NIST certified encryption is the best assurance that a solution meets your compliance requirements.

4. Are there any laws or regulations requiring businesses to protect their sensitive data?

Yes, there are quite a few, and many companies find themselves complying with multiple regulations. If you take credit cards, you fall under the Payment Card Industry standard. That’s a private regulation promoted by the credit card vendors such as Visa and Mastercard. If you’re a bank or engaged in the banking industry, you fall under Gramm-Leach-Bliley Act and FFIEC regulation for protecting data. In the health care industry, you fall under the HIPAA/HITECH acts.  FIRPA is the regulatory environment around educational institutions.

Individual states have passed data privacy regulations and defined data breaches and the penalties for them. And the federal government is moving laws through Congress to define protections for personal information. There are quite a number of regulations that define data that needs to be protected.

5. How would my organization develop a data security policy?

It’s a real challenge especially if you’re starting for the first time, it’s easy to feel overwhelmed when hearing about data breaches on a daily basis. Keep it simple to start. There are some things you can do that are very effective up front.  Rank where the vulnerabilities are. Here are just a few to help get you started:

1. Make sure you have good antivirus software on Windows and Mac.
2. Use good strong passwords. “1234” or “admin” are not good passwords!
3. Understand where your data resides and who has access to it.

Here’s another interesting thing, if you have a problem, it’s going to be your problem, not the vendor’s problem. It’s going to be your headache, your upset customers, and your financial loss. So pay attention to your encryption solution! 

Something that inhibits people from taking action is just thinking they are not subject to a data breach.  That’s a dangerous attitude. We've been saying it for years beause it's true - Data Gets Out. Encrypt it! 

Download the complete podcast here.

How Much Data Can You Encrypt with RSA Keys?

One of the differences between the two is speed. Symmetric encryption is much faster than asymmetric. The exact difference is implementation dependent, but may be on the order of 100 to 1000 times faster.

It is widely known that AES encrypts a 16-byte block of data at a time. However, how much data can be encrypted at one time with an RSA key is usually only discussed in vague terms such as “use RSA to encrypt session keys.” This raises the question of how much data can be encrypted by an RSA key in a single operation.

The typical encryption scenario is to encrypt with a public key and decrypt with the private key. OpenSSL provides the RSA_public_encrypt and RSA_private_decrypt functions to implement this.

The first parameter to the RSA_public_encrypt function is flen. This is an integer that indicates the number of bytes to encrypt. Its maximum value depends on the padding mode. For OAEP padding, recommended for all new applications, it must be less than the size of the key modulus – 41 (all in bytes).

To get the size of the modulus of an RSA key call the function RSA_size.

The modulus size is the key size in bits / 8. Thus a 1024-bit RSA key using OAEP padding can encrypt up to (1024/8) – 42 = 128 – 42 = 86 bytes.

A 2048-bit key can encrypt up to (2048/8) – 42 = 256 – 42 = 214 bytes.

We collaborate with developers and IT professionals around the world and know that they use a wide variety of languages and platforms to accomplish their work.  Our products include documentation, source code examples, and HOWTO guides for developers in order to help projects get done quickly. Visit our Developer Resources section of our web site to learn more and discuss your upcoming project with our development team.

Last week we presented a webinar on PCI requirements for encryption key management.  Many of the people who attended were encrypting data on the System i and curious about how to manage their encryption keys according to new PCI requirements. 

The way organizations are managing encryption keys is falling under more scrutiny by QSA auditors.  Companies must demonstrate they are enforcing dual control and separation of duties.  

How is this achieved on the System i? Is it still effective to use an integrated key management solution that is store encryption keys in the same partition as the encrypted data?  The answer, quite simply,  is "no" PCI DSS requirement states the following requirements for key management:

• Dual Control means that at least two people should be required toauthenticate before performing critical key management tasks.
• Separation of Duties means that the individuals managing encryption keys should not have access to protected data such as credit cards, and those that have access to protected data should not have the authority to manage encryption keys.

Now here is an uncomfortable truth.  On the IBM i you simply can't achieve these PCI requirements if you store the encryption key in the same partition as the protected data.  The QSECOFR user profile (and any user profile with *ALLOBJ authority) will always have complete access to every asset on the system.  An *ALLOBJ  user can circumvent controls by changing another user's password, replacing master keys and key encryption keys, changing and/or
deleting system logs, managing validation lists, and directly accessing database files that contain encrypted data.  

From the perspective of PCI, an integrated key management system puts too much control into the hands of any one single individual.
The only way to comply with PCI requirements for key management is to store the encryption keys off of the IBM i.  Take users with *ALLOBJ out of the picture completely.  When you use a separate appliance to manage encryption keys you can grant a user access to the protected data on the System i and deny that same user access to the key manager.  Now you have enforced separation of duties.  And with the right key management appliance you can require TWO users to authenticate before keys can be managed, and have dual control of encryption keys.

Let us know about the key management strategy at your company. Is your organization encrypting data on the System i?  How are you managing the encryption keys? If you store them on a separate partition, have you had a recent PCI audit?  What did your auditor say?

In our encryption practice we often help customers integrate the exchange of encrypted data between different applications within the organization, and between their own applications and a vendor’s or customer’s application. It is truly amazing to me how often we encounter non-standard encryption that makes this integration very difficult. The problem is not the lack of standards for encryption. Most compliance regulations provide clear guidance and references to encryption standards. Here is what the PCI Data Security Standard (PCI DSS) Navigation Guide says about encryption (my emphasis):

The intent of strong cryptography (see definition and key lengths in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or "home-grown" algorithm).

Strong Encryption:
Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher). See NIST Special Publication 800-57 for more information.

The problem seems to be a general lack of knowledge about encryption. And this applies to some vendors of encryption solutions. Here are a couple of examples:

One of our customers was having trouble decrypting a field with our software that was encrypted on a Windows server with “256-bit AES using CBC mode”. That seemed to be a pretty straight-forward task. Yet we couldn’t get the data decrypted properly. The output just looked like garbage. We spent a fair about of time with the customer verifying that they had the right decryption key, that the initialization vectors for the decryption were specified correctly, and that our software was being used correctly. But nothing was working. We then asked the third party software vendor to share their AES source code with us.  In this case the vendor was very accommodating and let us review their source code implementation of AES encryption.

Voila! The source code showed that the implementation was using a 256-bit block size for the encryption algorithm. The AES standard (FIPS-197) requires the use of 128-bit block sizes. The use of the larger block size meant that this was not even AES encryption according to the industry standard. The vendor fixed their implementation and the project was successful. But our customer spent a lot of time and money resolving the problem.

Another example of getting into trouble occurred with a customer who deployed an AES encryption solution that used the CUSP mode of encryption. This rang alarm bells right away.  We knew that CUSP was not one of the NIST approved modes of encryption, and we had never encountered it before. We quickly learned that CUSP stood for “Cryptographic Unit Service Provider” and was implemented by IBM in a couple of their server products. This customer had a couple of problems. CUSP mode was not a standard mode of encryption, and data encrypted with CUSP was not going to be decrypted by any of the standard open source or commercial products in the market. So this customer was locked into an incompatible encryption strategy.

The second problem is that the CUSP mode of encryption is a proprietary protocol.  The PCI DSS clearly states that strong encryption must be based on industry standards and not proprietary protocols (see above).  As I interpret the PCI DDS requirements for encryption, a customer using CUSP mode would be out of compliance. That’s going to hurt the next time a QSA takes a hard look at your encryption implementation.  We recently published a white paper on the weaknesses of the CUSP mode of encryption.  Click here to download it.

One way to insure that your AES encryption software is compliant is to look for a NIST certification. A NIST AES Validation certificate, or a NIST FIPS-140 certificate, is pretty good assurance of compliance. The FIPS-140 certification process requires AES Validation, so that certification is incorporated by reference. That’s why either certification will give you the assurance that AES encryption is being done according to the standard. Lacking certification, you are relying on the promises of a vendor or developer who may be ignorant, or have a motivation to be less than forthcoming. Not a good situation to find yourself in.

Both of these customers spent a fair amount of money fixing the problem.  An entirely avoidable expense.

Patrick