Dentrix claims it encrypts their data, but does it?

A few weeks ago, I had no idea what Dentrix software was. Now I’ve seen it mentioned in connection with two recent breaches involving PHI (the first one was this breach, involving an older version of Dentrix). Such coincidences often get my attention.

Dr. Rob Meaglia is a dentist in Rocklin, California. According to his December 21st letter to affected dental patients, a computer was stolen from his office suite on December 16 during a burglary. Patient information stored on the computer included “both medical records and dental insurance information, including Social Security numbers,” according to Dr. Meaglia.

But what caught my eye was that he informed his patients that the computer was password protected “and the software we use, Dentrix, encrypts their data.” (emphasis added by me)

But does it really?  The answer may depend on what you mean by “encryption” and what HenrySchein Dental means by it.

Dentrix’s advertising and marketing for Dentrix G5, which was the version Dr. Meaglia was reportedly using, claims their software provides encryption.  Their Dentrix G5 product sheet of February 2012, which is still available on their website lists “Database encryption and security” as the second feature.  They also advertise it this way:

Dentrix G5 starts with an enhanced technology architecture that builds on previous versions to deliver new levels of security, performance and stability.  This includes a new SQL database and improved software engine that increases reliability and overall performance, so your team can stay productive.  The database also provides new encryption capabilities that can help keep patient records safe and secure. And of course, encryption plays a key role in your efforts to stay compliant with HIPAA security standards. (emphasis added by me)

This November 2012 interview also emphasizes Dentrix G5’s “encryption.” Note that they do not claim their encryption provides safe harbor under HITECH. That’s not at issue here. What’s at issue is whether the security they provide qualifies as “encryption” at all.

Is Data Masking or Obfuscation “Encryption?” 

In June 2013, NIST basically rejected the descriptor “encryption” for FairCom’s  proprietary “standard encryption” (which is what Dentrix used in its G5 version). As a result of a vulnerability brought to CERT’s attention, FairCom  wound up re-branding  its “standard encryption” – which CERT described as a “weak obfuscation algorithm” – as “Data Camouflage.”  The CERT report includes FairCom’s description of its “standard encryption” and its new description for “Data Camouflage.” The corresponding NIST report can be found here.

I read all of the above and  the MITRE report and didn’t think that Dentrix’s “database encryption” would meet the definition of “encryption” as I understood the term.

In any event, Henry Schein, Inc. was notified of the vulnerability and re-branding on June 10, 2013.  So what happened then? Did they  send any alerts or notifications to clients who had purchased the system to make sure that customers understood that Dentrix only provided a weaker cousin, “data camouflage” and not strong encryption? No, they didn’t.

I spoke with a representative of Henry Schein yesterday. Their position is that FairCom’s “Data Camouflage” is still “encryption” under HIPAA regulations and therefore there was no need to contact customers or do anything differently. I am not a lawyer and so can not address any legal issues that might be implicated by claiming “encryption” if something is not “encryption,” but as a patient privacy advocate, I’d ask:

Might Dr. Meaglia (or other G5 customers)  have taken additional security steps if he understood that all his Dentrix software incorporated was what CERT describes as weak camouflage? Might  Dr. Meaglia  have sent a very different notification letter to patients and possibly offered patients some free credit monitoring services at his expense if he knew the data really weren’t as secure as he might have thought from the word “encrypted?”  Are  Dentrix customers misled by the use of the word “encryption?”

So I Asked Some Experts

Realizing that my gut response is not predicated on actual expertise with cryptography or data security, I asked a few experts to comment on the CERT vulnerability report and Henry Schein’s position that “Data Camouflage” is still “encryption” and they could call it that.

Matt Blaze, a cryptography researcher and Associate Professor of Computer and Information Science at the University of Pennsylvania, responded:

I will admit I’ve never heard the term “data camouflage” before now, and I suspect it should not be confused with encryption.

Christopher Soghoian, Principal Technologist and a Senior Policy Analyst with the ACLU Speech, Privacy and Technology Project, was also puzzled by the term and thought it sounded “fishy.”

Joe Lorenzo Hall, the Chief Technologist at the Center for Democracy & Technology, responded:

… Certainly, it wouldn’t be in the public interest if trivial encryption methods counted here (and the HHS guidance linked to above says that you shouldn’t store the key on the same device as the encrypted data… so they seem sensitive to folks screwing this up). I would want to see HHS be able to enforce against “ineffective encryption” I hope they would do so here.

[…]

No, a weak obfuscation algorithm is not encryption. The rule of thumb is that encryption uses math that is easy to do in one direction but very hard in the other direction without a secret that is not generally known or knowable. If they use the same key across their installations (which appears to be what the vuln report suggests) and someone could use a method to get access without that key, that is not effective encryption. It reminds me of Diebold and hard-coded passwords: in 2004, researchers found that the default password to every Diebold machine was 1234. Technically it did require a password, but practically that was worthless in terms if protecting access to the system and data.

Matthew Green, an academic at the Johns Hopkins Information Security Institute who’s worked on developing privacy-preserving cryptographic protocols, had this to say, after noting that he is not a lawyer and cannot speak to any of the legal issues:

In my opinion, the algorithms used by Dentrix aren’t really encryption, and shouldn’t be called encryption. I think it’s a lousy idea to use obfuscation algorithms that can easily be reversed, and even more dangerous to call them ‘encryption’ which might be misleading.

And Michael Ramirez, a former Department of Defense security architect who has a special interest in security for programs and apps for HIPAA-covered entities, responded:

“Encryption” claims should largely be looked at in the same light as clinical studies- any reputable findings should verifiable, repeatable, and (most importantly) peer-reviewed. Until then, any claimed benefit should be relegated to the equivalent of “encryption homeopathy”- it may make you feel better, but there’s little reason to place much stock in any specific claim. Indeed, FIPS 140-2 (Appendix A) was created to identify and certify encryption algorithms (and help agencies avoid encryption snake-oil).

Looking in detail at the available documentation, a couple of things are clear:

• Data “camouflage” appears to be little more than a purposefully obtuse encoding scheme. Within their developer documentation, they reemphasize that “It should be noted that any c-treeACE client can access camouflaged files unless a hidden key is provided …” This benefit of this protection is, therefore, based purely on scarcity and is dependent on how they control access to the c-treeACE clients. This is equivalent to claiming the data on your hard drive is protected because you use a Linux-specific encoding scheme when I use Windows or a Mac.
• It likely does not rise to the level of HIPAA Safe-Harbor- “FairCom designed its proprietary Data Camouflage algorithm for speed and efficiency, focusing on minimizing performance loss.” Keys are embedded, static, and shared- meaning that it likely fails to meet the the HHS encryption safe harbor requirements, specifically SP800-111: “Organizations should ensure that all cryptographic keys used in a storage encryption solution are secured and managed properly to support the security of the solution.” The use of this option is a conscious trade of security for performance/convenience. It certainly fails all of the security best practices, such as the Cryptographic Storage Rules guidance provided by OWASP.

In general, obfuscation is somewhat controversial topic with security and cryptography experts. Much like the “alternative medicine” debate, there are undoubtedly some benefits when used in conjunction with traditional, verified approaches. But because it can also quickly provide a false sense of security and may make people less likely to pursue tried-and-true solutions, some believe it only confuses potential users and implementers.

So it seems that my concerns about describing the system as providing “encryption” and possibly leaving covered entities with a false sense of security has some basis. But of course, the camouflage is only one issue. The other issue is the hard-coded password.

Exploiting a Known Vulnerability to Access Patient Data

Apart from the issue of what you call it, Dentrix G5 has a second and unremedied vulnerability whereby an attacker can access the patient database if they have knowledge of the hard-coded internal-database password that is shared across different customers’ installations. That vulnerability was reported by CERT  to Henry Schein in November 2012. In response, Henry Schein issued HotFix 1 in February 2013, which supposedly remedied the problem. But according to the researcher who identified and reported the vulnerability, it didn’t. And neither did Hot Fix 2.5, he claims. The spokesperson I talked to informed me that HenrySchein Dental is working closely with FairCom to close that hole/fix that vulnerability, but in combination with the other issue, the overall security for patient data at rest seems quite concerning to this privacy advocate.

In my conversation with the Henry Schein representative, I made certain recommendations that I will repeat here:
1. Change literature on the Dentrix website to be clearer/more transparent about the level of security Dentrix provides for the patient database at rest.
2. Offer helpful resources on their site so that potential customers who are not tech savvy will have a better sense of some of the other elements they will need to address or incorporate to achieve HIPAA compliance for technical and administrative safeguards. In my opinion, it’s not enough to say a product will help achieve HIPAA compliance without at least pointing out  some of what it doesn’t help with or what’s missing.
3. Use – or at least give customers the option to use – AES encryption, which, based on my understanding, FairCom did and does have available, but Dentrix chose not to use or make available as a feature. And of course, and as they acknowledge and are working on:
4. Allow customers to set their own root password. Concerns about customers who might wind up locking up their database and forgetting or losing the key is not a justification for hard-coding a default login across installations, which is a well-known security risk.

To be clear: I am not saying HenrySchein Dental is doing anything worse than any of their competitors. They believe they are in the forefront and will continue to be a leader in the development of office practice management systems for the dental profession, and I do not doubt that. All I’m saying as a privacy advocate is that I’m concerned about the existing security for data at rest in G5 and I think Dentrix needs to be much more transparent with covered entities about its data security limitations while it strives to close existing vulnerabilities and improve its product. Because if the dentists don’t understand what they’re not getting, it is the patients’ data that will be at risk.