How to tamper with electronic health records ...



Well - this essay is in fact about how any document on literally any computer system can be tampered with. Electronic health records are just one good example where it becomes obvious that a "closed" computer system is always untrustworthy regarding data integrity.

Under "closed computer system" we understand a single computers or a cluster of computers connected together in a local network. No data leaves the system.

It is obvious that medical health records need to fulfil the following criteria in order to be useful in a court case as evidence:


  1. proof of authorship: this can be achieved with digital signatures. It is an entirely different can of worms from our topic here and will not be discussed

  2. proof of integrity: you must be able to prove that the records could not have been altered since they have been generated for the first time. This includes both accidental (data corruption) and illegitimate (data tampering) alterations.

It is not too difficult to prove absence of data corruption, simply by using strong checksum algorithms (like MD5) - we will not discuss this topic yet. Here we will focus on the possibility of illegitimate document tampering and how to prevent it.

Are you sure that your system is tamper proof? How would you know? What if it comes to a court case, and all that is between winning the case or losing your medical registration are your electronic health records, and all of a sudden an IT expert enters the witness box and proves that you can't prove that your health records have not been illegitimately altered?

This is such an important issue that you must not succumb to believe commercial blurb. You must check yourself, you must find out how exactly data integrity is guaranteed on your system, or you should not risk going paperless.

There are misinformed or even dishonest software vendors who claim that they can prevent data tampering in a reliable way by several countermeasures, including:

  1. password protected access restriction

  2. non-disclosure of internal data structures and file formats

  3. leaving "secret" audit trails on the hard disk

  4. encrypting information

I will now demonstrate one by one how these countermeasures can be circumvented. Most software vendors are of course using a combination of all these measures in the attempt to make it more difficult to "hack". ". I will show you that all they achieve in reality is to waste a little more of the "hackers" time.

After this demonstration, I will present a generic approach how any document can be modified regardless of the software that was used to generate the data without any need for so called "hacking". This generic approach is a proof for the impossibility of proving data integrity in a closed system.

Before you despair and abandon paperless health records, I will show you that it is perfectly possible to guarantee data integrity with little extra effort- an effort that should be undertaken by your software vendor.




  1. password protected access restriction

    If the program relies on password checking alone to give you access to the data, and does not protect the data otherwise, it is easy. You simply access the data with different software (like text editors in the most simple case). Health IT is a serious business. Confidential patient data should not be entrusted to a security “system” that can, in the most simple of cases, be bypassed by simply opening up a data file in a text editor. In some cases, the password is used to unlock data encryption. Unfortunately, this approach makes it all too easy to circumvent anti tampering provisions.

    A program is nothing but a flow of instructions. The program flow branches to different subroutines depending on information. Common password protection schemes include subroutines that check the password against a hash code of that password (i.e. they do not store the password itself). The routine that checks the password branches to different subroutines, depending on whether the entered password was right or wrong.

    With basic software tools called "debuggers" and "disassemblers" it is possible to reverse engineer binary program code intohuman readable form and execute program instructions step by step. That way, it is possible to find the subroutine that decides which way to branch: either to accept or to reject the password. From here it is simple just to swap the branching, so that the program will accept the password whenever it is wrong.

    Software vendors have tried many different approaches to make this procedure more difficult, but a quick look at the computer game market shows that there is no sofware resistant to reverse engineering for a long time.




  2. non-disclosure of internal data structures and file formats

    Reverse engineering data structures and file formats is often easier than reverse engineering password access. Most structures can be found out using a binary editor (sort of a text editior that gives you direct access at byte level to information stored on the hard disk) and searching for patterns.

    As you can use the software that generated the pattern, you can save the file containing the information you want to manipulate, enter some information, compare the altered file with the previous file for differences. There are good software tools freely available (like "diff") that make this process very easy.

    Repeat this a few times, and you will get enough information to reconstruct internal data structures and file formats.




  3. leaving "secret" audit trails on the hard disk

    In this case, I can save the status of my hard disk before installing the software and after using it, and then compare the differences as outlined above. Writing information to the hard disk means calling subroutines provided by operating system or BIOS (Basic Input/Output System). Calling these subroutines can easily be intercepted, and a filter in the intercepting subroutine can comfortably log any write access for my perusal. It is not possible to hide write access to the hard disk, and it is not possible to prevent me from finding out what has changed on the harddisk between two different times of software use.




  4. encrypting information

    This is often the hardest nut to crack, and sometimes impractical. Most software vendors seem to rely on flawed or simplicistic cryptography provided by 3rd party vendors who are notorious for incorrect implementation of security tools (such as Microsofts implementations of a virtual private network PPtP: read about it here - a basically reasonable technology, particularly useful for linking surgeries together, has been compromised by artificially reducing the keyspace and other flaws). Companies selling "password recovery" for many of the popular software packages such as Microsoft Access are abundant on the net, examples are found here and here, but you may find better ones using your favourite search engines.

However, we don't have to waste too much time trying to circumvent cryptography. In most cases, we can trigger the internal decryption routines without need to know about them simply by using the password reverse engineering approach. Although I haven't come across a medical software package yet where this would not yield the desired result, I will now outline a generic approach how any anti-tampering method of any software vendor can be circumvented, provided no data leaves our closed system before the tampering happens.




A generic approach towards tampering electronic health records


  1. Generate an exact byte-by-byte replica of my hard disk partition and my BIOS settings. Tools like "Partition Magic" or the free GNU Parted make this very easy and straightforward. Most modern mainboards with flash BIOS come with utility software that allows you to save your BIOS settings - but there are more sophisticated tools freely available on the net. Partition image and BIOS image together represent a true „snapshot“ of a computer system for any given time. Cheap storage media like CD-R, allow to generate snapshots as often as necessary. Restoring from; a snapshot will exactly reproduce the status of a system for any given time.

  2. Install a software utility which intercepts all input events (mouse, keyboard) and stores them time stamped in a log file. This is particularly easy in the Windows environment. You can write your own if you have basic programming skills in low level languages such as C, or you may contract a programmer to have it written for you, or you can search the web for such tools - they do exist .

  3. Suppose you want to illegitimately alter electronic medical records from last year. Without any knowledge about the file structure or the cryptographic features of the medical software package that was used to generate and save these records, you would simply open the last log file before that time, search for the entry you want to change, and enter as many keyboard / mouse events as necessary.

  4. After restoring the BIOS settings and restoring the partition image onto the hard disk you would replay all captured keyboard and mouse events (including the ones you just manipulated). A good interceptor utility would adjust the hardware clock accordingly during playback, thus making it impossible to track the changes down later on.

The health record has now been altered, and neither your medical software nor any other software on your computer would have been able to detect the manipulation. It would be impossible for even the best IT specialist to detect it

In practice, it is not necessary to resort to such methods. Simple reverse engineering and „hacking“ is virtually always successful.
You don't believe me? Have a look at this page.

On a similar line it should be mentioned that software can't even be sure it is running on the platform it supposes it runs. Hardware emulators and "virtual machines" blossom the more restrictive hard- and software vendors get; software like "vmware" for example allows to create virtual machines that to any software look like a standard PC running Windows 98 or Windows NT, yet they might run on some UNIX operating system running on some exotic processor with hardware entirely different to what Windows system calls will make the software believe. It is a fact that software never can safely make any assumptions as to which platform and hardware it is really running on, let alone finding out at what time it is running. It is too simple to emulate even connections to time servers on the net It should be obvious by now, that it definitely impossible to avoid tampering under these circumstances.

Even Microsoft has realized that "resistance is futile", that it is impossible to make any software defense mechanism uncrackable. A quote from their own web site :

" ... But given enough time to scour the operating code for the lines that operate the softwares defenses, a skilled cracker can always find them and remove or disable them no matter how carefully they are hidden and disguised. In the software piracy game, the attacker always has the advantage he is invisible, he has as much time as he needs and he is often as skilled as the defender. The defender can watch how the cracker operates, learn from the way he exploits the code and close the holes he exposes, but because of the open nature of the personal computer it is next to impossible to design a piece of software that can never be cracked . The trick is to come up with new defenses that will be unfamiliar to crackers, to make cracking such a laborious, time consuming process that it takes weeks and weeks to find and disable every carefully hidden piece of code. ... "


Now you should go to this page to learn how you still can prove the authenticity of your digital documents.

[back]

(c) 2000, 2001 GNU Free Documentation License Dr. Horst Herb, hherb@gnumed.net