FIPS 140-2 security testing for wireless medical devices

JAY WHITE | LAIRD CONNECTIVITY

Design engineers should be aware of several testing issues surrounding encryption standards designed to protect data from bad actors.

The bad guys don't care about your social security number and credit card numbers as much as you might think. Stolen security numbers are almost literally a dime a dozen on the darkweb: You can buy them for less than a dollar apiece. And credit card numbers aren’t much more valuable: They often just fetch $5 a card. If you sold both to a hacker, you would barely have enough to pay fora latte and leave a decent tip for the barista. These price tags might seem surprising, given how much effort people and companies put into trying to keep SS#s and CC#s secret. But clearly that’s not what online criminals are shelling out their ill-begotten dollars and rubles for.

But hackers and fraudsters are willing to pay for medical health records. Those are where the action is at on the dark web. Becker’s, the influential healthcare publication, reports those fetch $1,000 on the dark web. It’s no wonder, then, that hackers have their eyes on the IT systems of hospitals, clinics and other healthcare organizations. That includes wirelessly-connected medical devices, which may be viewed as a way to gain access to IT systems and to gain visibility into confidential patient information. To counter this threat, regulators and the healthcare industry have focused on the security of these devices, and FIPS 140-2 is critical to the next wave of security measures.

FIPS 140-2 didn’t originate in healthcare. It is a security standard the U.S. government uses for protecting sensitive but unclassified information in IT devices and systems. FIPS stands for Federal Information Processing Standard, and encryption is at the heart of how it protects data both in motion and at rest. Encryption for information that is in transit has been a common element of security protocols for quite some time. Before data is sent from point A to point B, it is encrypted at the beginning of the journey and then decrypted at the other side. This type of encryption even pre-dates the computer age. The Romans used a version of this technique to deliver secret messages to military commanders. The same principles are behind the encryption of data in transit today, but with 256- bit encryption rather than an alphabet cipher that Julius Caesar used. The other key kind of encryption is for data at rest, which is about protecting it anywhere it is stored. This is particularly important for wirelesslyconnected devices, used to hold confidential information.

Those two types of protection are both vitally important for healthcare, where electronic health records and confidential patient data is not only being sent back and forth between devices and healthcare IT systems, but also residing on medical devices. FIPS 140-2 may not have been designed with healthcare in mind, but it’s become the gold standard for securing patient information and is being rapidly adopted by healthcare companies and device manufacturers. For those wanting a deeper dive into how FIPS 140-2 protects healthcare data, my colleagues recently published a white paper, “Understanding Data Encryption and FIPS 140-2 Within the Healthcare Environment,” that is an excellent resource. It explains how this data encryption is useful for healthcare and provides practical guidance about how it fits into a broader security strategy for healthcare companies.

The industry is moving toward broad adoption of this security standard in a way that will make FIPS 140-2 compliance and certification a critical requirement for engineering teams bringing wirelesslyconnected medical devices to market. There are a number of key takeaways from my own team’s experience that can be instructive. We hope this serves as a practical checklist that will help your FIPS 140-2 compliance and certification processes be successful.

• FIPS-Compliant is no longer enough – FIPS certification is complex, so most companies in the industry made the practical choice to have “FIPS-compliant” status as their target. Encryption was implemented through FIPS-validated software such as Open SSL, and that was seen as meeting the necessary threshold for compliance. As the healthcare industry has put a stronger focus on preventing breaches, their expectations about FIPS adoption has shifted as well. Increasingly, the healthcare buyers of medical devices are requiring official FIPS certification. Devices that are only FIPS-compliant are increasingly a deal breaker, which puts the responsibility on design engineers to make device-level certification a mandatory element of their project plans.

• CMVP is the gatekeeper for being FIPS-certified – To achieve devicelevel FIPS certification, you must successfully navigate CMVP, the Cryptographic Module Validation Program. This is the certification program created jointly by the U.S. and Canadian governments to provide a uniform certification process for manufacturers in both countries. This might be a new acronym for design engineers familiar with agencies regulating wireless products and medical devices, but it’s a critical one. CMVP has accredited independent labs in both countries that specialize in cryptographic and security testing to ensure products meet the standards and can get the FIPS-Certified seal of approval.

• All cryptography is not the same – One of the most important things to know about the CMVP testing process is that there is specific criteria for how cryptography is implemented. Engineers who have utilized cryptographic capabilities in the past likely haven’t faced the specificity of CMVP’s standards for encryption, so it’s important to understand what is permitted and what is not. To be approved, sensitive patient data must be encrypted with an approved algorithm. For that reason, the safest route is to choose an FIPS-validated encryption module, which already checks the box for passing this part of the certification process.

• Know your boundaries – CMVP prescribes encryption technology with no flexibility: Either the crypto module is approved or it will be rejected. But design engineers have more flexibility in setting the boundaries of how encryption is used in their product.

There is the option of setting a broad boundary that encompasses the entire device, or you can set the boundary more narrowly to only focus on the cryptographyrelevant components. As an example, one of the key decisions designers will need to think through are the concepts of Data in Motion and Data at Rest and how they relate to your boundary.

Data at Rest means the FIPS boundary includes data that is stored on the device (hard drive or similar). Data in Motion means the data-path that is transmitting the data is encrypted using a FIPSvalidated crypto-module. Your team should be thinking as early as possible about the boundary you will present to the CMVPaccredited labs because that will steer the entire testing process later on.

• Start as early as possible because there are two steps – For early planning, it is important to think about FIPS 140-2. Every engineering team knows that certification is time consuming, but many may not realize how long FIPS certification takes. The process commonly requires 12-14 months – and that’s when things go smoothly. It can take far longer if there are setbacks.

The process takes that long because it’s actually two processes: In the first step the certification lab does a design review, boundary review and architecture review. In the second step the lab submits the data to NIST in the U.S. or its Canadian counterpart for review. Engineering teams must build this into their project timelines as well as begin steps in the FIPS process as early as possible to avoid delays in getting products to market.

• The fastest route may be a validated module – It is possible to tackle these projects using a combination of software packages and other components to buildout all of the elements that will achieve FIPS 140-2 certification. Those tools are readily available. My team worked with many of them as we explored various paths in our own FIPS 140-2 design strategy and certification plan. What we found, though, is that the do-it-yourself route is slow, complex and expensive.

The lesson here is similar to that from wireless certifications with regulatory agencies like the FCC. Yes, it’s possible to design something from scratch that will get FCC approval, but it usually makes more sense to use a precertified module. Using a FIPS-validated module will similarly streamline the process by checking many of the boxes the CMVP labs will look for.

This approach is particularly impactful for the first step in the certification process (step 1 where the certification lab does a design review, boundary review and architecture review), potentially accelerating that phase of the process because the lab will have immediate clarity into and confirmation of the device’s adherence to many FIPs criteria.

• Know your level and set your calendar – There are a couple of additional pieces of advice useful for effective FIPS 140-2 planning. First, FIPS 140-2 has four different levels, and picking the correct one is a critical early step in your design project. The white paper mentioned previously has a detailed discussion of the four levels and for which devices each one is relevant.

Most devices only need Level 1, the simplest level to achieve. Other devices, however, may require Levels 2, 3 or 4 – each of which are more involved. Not looking closely at the four levels and selecting the wrong one will likely guarantee major setbacks later in the certification process. So be sure to examine the four paths at the beginning of the design process.

The other caveat is about the requirement that FIPS certification be renewed every five years. Unlike some other certifications, it does not last for the life of the product. Your organization will need to map out a strategy for scheduling and conducting certification future renewals to ensure products retain their certification and can stay on the market.

I hope this article serves as a practical road map for your team as you proceed with projects that must achieve FIPS 140-2. Note also that there is a new version of FIPS on the horizon – FIPS 140-3. That said, FIPS 140-2 will be around for quite a while until 140-3 becomes the dominant protocol. Knowing how to successfully implement FIPS 140-2 will be a vital skill for design projects for the foreseeable future.

Even small mistakes with FIPS 140-2 can have major consequences in time to market. Doing the right up-front planning and architecting for FIPS 140-2 can help engineers avoid long delays and high costs that would interfere with a successful product development timeline.

References: Laird Connectivity, https://www.lairdconnect.com/

White paper, Understanding Data Encryption and FIPS 140-2 Within the Healthcare Environment, https://www.lairdconnect.com/ resources/white-papers/understandingdata-encryption-and-fips-140-2-withinhealthcare-environment

FIPS 140-2 security levels

Level 1 Examines the cryptographic components of your module’s software. Requires production-grade components but no specific physical security mechanisms.

Level 2 Adds physical security to the software component. Requires physical tamper-resistance (such as tamper-evident coatings or seals or pick-resistant locks) and role-based authentication.

Level 3 Adds physical security to the software component. Requires a tamper-proof container to protect the code to prevent intruders from gaining access to the CSPs (critical security parameters) located within the module.

Level 4 The highest level of security which provides complete protection around the module. Beneficial for modules located in physically unprotected environments or for modules that risk security compromises due to environmental conditions such as temperature fluctuations. Adds physical security to the software component. Requires that the physical security mechanisms are “tamper-active” meaning that the contents of the module are deleted or destroyed if it detects an environmental attack or is physically compromised.