Technology Exploration Project – M591

Patents Don't Protect Privacy

The fact that a secure data system is patented does not protect its users privacy, although it can often be marketed that way. The patent can actually be used to expose vulnerabilities in the system, and because it is a patent, there is no motivation for people to help improve the system.

To explore this idea I will look at two products, iMedica and FilesAnywhere, which are both secure data systems for accessing data across the Internet, and both use a patent system to help protect their user's privacy and anonymity. iMedica is a specialized medical records system. It is a system designed to handle all aspects of administration for medical professionals and clinics. FilesAnywhere is a more general data system.

The information contained within the patents can expose system vulnerabilities

iMedica's patent describes how their system breaks the patient's information into two sections: an encrypted personal details file an unencrypted medical records file. The two files are linked with an identifier so that, once the personal details are decrypted, the two can be cross referenced.

Personal details include name, address, social security number, date of birth, phone number and insurance number. Medical information includes the date of a visit, symptoms, what tests were run, the results of those tests and prescriptions. These two sets of data are separated,and two keys are concatenated to each. One key is used to link the two files, called 'patient_id', and anther key is used to link both files to the clinic that the files pertain to, called 'clinic_id'.

The personal details file is then encrypted using a symmetrical encryption algorithm and a key chosen by the clinic. The medical record file can be encrypted but generally is not for three reasons. Firstly, the file is generally much larger than the personal details file, and will grow with each visit made by the patient to the clinic. This means that encrypting the medical file would take longer than encrypting the personal file.

The second reason to not encrypt the medical file is that leaving the file unencrypted does not compromise security. This is because the medical file is not considered to be confidential information, as it contains no reference to a particular patient. This is an area where the patents method declares itself different from the established method of encrypting files. Usually, a file's content is encrypted and its identifiers are left in plain text. The iMedica system assumes the medical file to be the body, which is left in plain text, and the personal file to be the identifier, which is encrypted.

Finally, the medical records file, if unencrypted, can be used by other groups for other purposes. Especially mentioned in the patent is the use for medical research. Is medical research useful without personal information? Most research requires some kind of personal information, for example age or sex, for it to become useful. If this information is kept in a separate encrypted file then it will not be available to the researcher.

Medical record details are personal once they are identifiable

The medical records files will not yield any personal information by themselves. However, if an individual person is targeted then that person's medical record could easily be deduced by observing other facts about that person. For example, the time and date they visit the clinic is stored in the unencrypted medical record, and can easily be found out about a person but observing them. Encrypting the personal file whilst leaving the medical file open prevents someone from going from a state of knowing medical details to knowing personal details, but it doesn't prevent people from knowing some personal details and obtaining medical detains. As soon as the connection is made between the person and the medical record, the information becomes very private.

The patent also describes how a second clinic can be granted access to the records by means of a temporary special key, and without knowledge of the first clinic's key. The first clinic, who has access to the record, creates a special key. It then uses the special key to encrypt the clinic's key, the patient_id and the special key itself. The special key is then given to the second clinic. When the second clinic produce this key to the system, it encrypts it with itself and compares the result to the stored encrypted special keys. If a match is found, the system uses the special key to decrypt the clinic key and the patient_id and then locates and decrypts the patient record. When the second clinic logs off, the keys are deleted.

The problem with this is that in normal operation the personal details are not decrypted until they reach the clinic. In this instance the server has to decrypt them to avoid the second client knowing the clinic key, and so it relies on a secure transmission medium, namely SSL, to keep the information secure. SSL is considered a secure protocol. However, there have been security problems with certain implementations of SSL (Cisco Warns of SSL Vulnerability, 2005).

The alternative offered it to give the second clinic the clinic key. This has a heavy privacy penalty, because then the second clinic has access to all of the personal files encrypted by the first, not just the particular file requested.


The patent for the FilesAnywhere product describes how the system stores and retrieves files. The file identification is stored in a database, while the files themselves are compressed and encrypted and then stored.

Setting up a FilesAnywhere account requires creating a username and then associating your full name, address, telephone number and email address. The username and email address are used by the system as identifiers. You are emailed a temporary password and then are prompted to change this upon first login.

FileAnywhere's password recovery system is a major weakness, especially if you have used the system to share files with other people. When you do this, FilesAnywhere sends that person an email with a link to the file, but also you user name and email address. With this information you can initiate the password recovery process. The next step is to either have the password sent in a plain text email to the stored address or to reset the password via the web page if you know the answer to the secret question defined in the account setup stage.

The email is susceptible to the known email attacks, including packet sniffing and known vulnerabilities in mail and webmail applications. You could also use the email address to mount a DoS attack (Yanik & Gutub, 2000). A possible solution to the email vulnerability is to use asymmetrically encrypted email. The secret question is not a a very good substitute password system, as they answers given to typical questions are easily guessable (The Curse of the Secret Question, 2005).

Setting up a free FilesAnywhere account requires creating a username and then associating your full name, address, telephone number and email address. If you opt for a larger or more feature rich version, you also need to provide billing information. The username and email address are used by the system as identifiers. You are emailed a temporary password and then are prompted to change this upon first login. If the security of this system is compromised, all of the stored files and this personal information are compromised. This level of information is unnecessary for a free account.

Talking of copyright material, FilesAnywhere say not to upload them "unless you are the owner of such rights or have permission from their rightful owner to post the material and to grant to FilesAnywhere all of the license rights granted herein". This is a major privacy issue as it implies that FilesAnywhere have access your encrypted files.

How the security of a system is marketed can give false weight to the patent

iMedica market their product to medical clinics of every size. Because of the size of the iMedica product, the security is not a major selling point. System stability, ease of use and compatibility with exiting products feature much more prominently. Where the security prowess of the iMedica system is touted is in regard to the convenience of having access to medical data "Anywhere, Anytime" (FAQ, n. d.). iMedica rely on the fact that their system is patented to market their product as secure, and simply state that it is the best security possible.


Clipping from iMedica FAQ

FilesAnywhere use a very contrasting marketing strategy regarding the security of their product when compared to iMedica. The fact that the under-pinning system is patented is only mentioned as a legal footnote. Instead, FilesAnywhere relies on the use of technical acronyms to demonstrate to the customer how secure their system is.


Clipping from FilesAnywhere

The FilesAnywhere product is also marketed at a broad range of user sizes, from individuals to large organizations. Their use of the more open approach of saying what protocols the FilesAnywhere system uses ties in with the fact that the product can be purchased online. The iMedica product is packaged system, and so sales people from iMedica can expand upon the security and privacy aspects of the product.

An 'open source' style approach would lead to greater privacy

Because the owners of these patents are granted a monopoly on their use, there is no incentive for people who spot potential flaws in the system to come forward and improve it. If the system was like an open source project, the security holes could be spotted and rectified, but patented it seems somehow static. Of course, the systems themselves are based on the patents and do not necessarily stick to the patents exactly.

The fact that a system is patented is also used to suggest that the system is therefore inherently more secure or privacy aware. This is not the case, it simply means that there is a monopoly on the use of the system. This can can be misleading to customers, as patents do not protect their privacy.

Appendix

To test FilesAnywhere is did the following:

• I signed up for a FilesAnywhere free basic account from here: https://secure.filesanywhere.com/UserNew.asp?REF_ID=&FREETRIAL=Y
• I then tried packet sniffing the network to capture data and usernames and passwords using WireShark, available here: http://www.wireshark.org/
• Packet sniffing was successful when the optional SSL login was not used.
• I then attempted to use the password recovery system to break into the account, using packet sniffing and investigating the potential for breaking the secret question.

References

FilesAnyWhere. (n. d.). FilesAnywhere: You've always got it. Retrieved November 26, 2007, from http://filesanywhere.com

iMedica. (n. d.). FAQ. Retrieved November 26, 2007, from http://www.imedica.com/FAQ.aspx

Koo, C. & Shyy, Y.. (March 2005). Medical records data security system. Retrieved November 26, 2007, from USPTO: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=3&f=G&l=50&d=PTXT&S1=6874085&OS=6874085&RS=6874085

Meyer, E. & Mundry, U.. (November 2001). Method and interface for a centralized archiving and de-archiving system. Retrieved November 26, 2007, from USPTO: http://patft.uspto.gov/netacgi/nph-Parser?u=%2Fnetahtml%2Fsrchnum.htm&Sect1=PTO1&Sect2=HITOFF&p=1&r=1&l=50&f=G&d=PALL&s1=6321254.PN.&OS=PN/6321254&RS=PN/6321254

Myser, M (2005). Cisco Warns of SSL Vulnerability. Retrieved November 26, 2007, from eWeek.com: http://www.eweek.com/article2/0,1759,1851584,00.asp

Schneier, B. (2005). The Curse of the Secret Question. Retrieved November 26, 2007, from Schneier.com: http://www.schneier.com/blog/archives/2005/02/the_curse_of_th.html

Yanik, T. & Gutub, A. (2000). Vulnerabilities of e-mail services. [Electronic Version] Computer and Network
Security. Retrieved November 26, 2007, from http://islab.oregonstate.edu/koc/ece478/00Report/GY.pdf