HP 680n - JetDirect Print Server White Paper page 10

Our imaginary customer is evaluating encrypting hard drives for his printers in the finance
department. The customer is confident all other ways of accessing these sensitive documents have
been closed and is now trying to close the final way – a forensic analysis of a printer's hard drive by
a hacker that is able to get his hands on one. The customer's main worry is that the electronics
recycling firm being used by him is actually owned by a larger corporation that is a fierce competitor
to the customer's own products, which may lead to some conflicts of interest and hacking
opportunities.
The customer purchases four different encrypting drives from different manufactures and places each
one in a different printer. After a few days of use, a question occurs to the customer: "How do I
know these devices are actually encrypting data? How do I know that they aren't just regular hard
drives with a high price?" The customer decided to run his own tests. He sent each printer the same
file – a 500 page ASCII text document filled with the letters of the English Alphabet (e.g.,
"ABCDE..."). He then removed each drive and placed them one at a time in a free drive slot in his
own computer. He then ran some tests.
Hard Drive A: The document appeared to be encrypted, but the meta-data about the document (e.g.,
author, title, date, and so on) was used for reporting and was not encrypted.
Hard Drive B: All the data was encrypted using AES-256. Unfortunately, the key was simply a
SHA-256 (Secure Hash Algorithm with 256 bits of message digest) hash of the hard drive serial
number.
Hard Drive C: All the data was encrypted using AES-256. Unfortunately, the key was simply the
first 256 bits of the actual data of the document being sent.
Hard Drive D: All the data was encrypted using AES-256 and the customer wasn't able to find the
actual key value. Looking at the manual for the drive, the manufacturer indicated that a random
number was used as the key and was unique to each drive.
The customer had a good friend who was also a very good hacker. He gave Drive D to his friend and
asked him to find out the contents. In about an hour, the friend returned with the document that was
printed. The customer was dismayed. It seems that the company that made Drive D did indeed
store a random number for each drive, but they kept track of the actual value and correlated it with
the serial number. A disgruntled employee of the company had posted this serial number-to-key
database to the underground hacking community.
The customer was upset at what he saw as horrible implementations of security. He immediately
went and looked at the manufacturer's warranty statements. Dismayed, he saw that the hard drives
themselves were under standard warranties, but the encryption function was under a "use at your
own risk" warranty. Unbelievable! The customer didn't have a legal recourse, so he thought he
would do as much as he could to educate the public about these questionable products, hoping that
consumer pressure would result in better products. On his blog, he posted his test results in great
detail. He was immediately taken to court by the four encrypting drive manufacturers for violating
the Digital Millennium Copyright Act (DMCA) and taken to jail.
What can one do when it comes to verification of a security product claims? That is a very good
question. We probably need to start with what standards the product is compliant with, such as
Common Criteria Certifications (CCC) and Federal Information Processing Standards (FIPS) as a way
of "limiting the field" of products so to speak. It is much better to start with products that have
compliance with some security standards; we just need to make sure that we do not stop there. We
can then look at whether the product has passed any independent third party testing (by someone you
trust of course!). We may want to do our own testing as well (just be careful what you do with your
findings). Much like scientific theories, there can never be complete verification of the functions of a
security product. Remember, at one time everyone believed the world was flat. Based upon the
information they had at the time, that was a reasonable belief to have. As time moved on and more
things were discovered, maintaining the world was flat was no longer reasonable. If our best
theories can be proven false at any time, including the theories used to develop security products,
how can product verification be done? This is the "Verification Problem". We attempt to combat The
Verification Problem with Testability and Falsification. In short, some things that are important are the
following:
Are the claims made by the security product testable? Who tested them? Is there on-going
•
testing? Are the testing results public? Have the claims been independently verified?
10