Below is a comment I posted to Jon Callas' blog post, "The Strange Rise
and Fall of Hardware Disk Encryption" (awaiting moderation).
Hello Jon,
I think it's interesting that you are declaring the "fall" of hardware
disk encryption just as most of the major HDD vendors are announcing
self-encrypting drives (both HDD and SSD).
I'd like to address some of the points you make in this blog posting,
as there is a lot of misinformation. This is "Part 1" of my reply, as
I don't have time to address everything today.
First, while it is true that most "hardware" devices are a mix of
hardware and software (or "firmware" as it's generally called in the
embedded world), there is usually a clear separation within the
devices regarding which functions get implemented in true hardware
(usually for performance reasons) and which functions are implemented
in firmware running on the device's microcontroller. The
microcontrollers used on modern drives are NOT fast enough to handle
encryption running at the full data rate of the drive (at least not
*real* encryption, e.g. AES... maybe it could handle the snake oil
examples you give, but probably not at the full data rate). For AES
encryption at the full data rate, a true hardware AES engine needs to
be added into the drive's electronics (either as an additional chip on
the PCBA or integrated into the drive's main controller chip... I've
seen it done both ways).
If the encryption is implemented in true hardware in the data path of
the drive, and if the encryption engine runs faster than the maximum
data rate of the drive, there is ABSOLUTELY ZERO performance impact,
contrary to your assertions that in-disk encryption increases the
latency by 15-20%. OK, maybe I shouldn't say ZERO, because there is
*some* latency added by the introduction of an AES hardware engine -
one cipher block's worth. AES-256 requires 14 rounds of encryption
per cipher block, so assuming one round per clock cycle, and being
fast enough to keep up with the maximum data rate of the drive, the
added latency is less than 200 nanoseconds.
Regarding all of the deplorable snake oil disk encryption products
that you mention, I agree with you that these are deplorable. But I
have never heard of any of these companies before. They're probably
out to make a quick buck while investing as little as possible in R&D,
and sell their products to those who don't know any better. On the
other hand, the major drive vendors who have announced self-encrypting
drives (Fujitsu, Toshiba, Hitachi, Seagate, and Samsung) are all large
companies with reputations to defend, and with significant R&D
budgets. We consult with security experts from other industries. We
scour the available literature on encryption and security (of which
there is no shortage). At Fujitsu we take security very seriously,
and I'm quite confident that the other major drive manufacturers do,
too.
Regarding your assertion, "it is safe to assume that an encrypting
drive is using ECB or worse, unless there's documentation to say
otherwise," I'd like to point out that the NIST AES Validation List
offers a reliable source of cipher mode documentation for many of the
drive vendors making self-encrypting drives. You'll note that the ECB
"mistake" has been corrected by at least one company in
newer-generation product.
Is it possible that mistakes will be made in hardware disk encryption?
Of course. I think the use of ECB by certain vendors was one of those
mistakes. When such mistakes are identified, they get corrected in
follow-on products, similar to how mistakes/vulnerabilities are
corrected in software crypto products.
As far as the requirements for the Opal specification, you are correct
that Opal does not mandate a certain cipher mode. However, it DOES
mandate that the drive's cipher mode is DISCOVERABLE by applications
running on the host computer (the "Mode" column of the K_AES tables
reports the cipher mode). This was somewhat of a compromise... It
allows for legacy silicon that only implements ECB to still be
"Opal-compliant", and it also allows the software application managing
the drive to decide if the drive meets a minimum security requirement.
If the drive reports ECB, the software application is free to use
software-based encryption instead of relying on the drive's
encryption.
I would also like to point out that an Opal-compliant drive is just
one component of a disk encryption solution. Another critical
component is the host-side software that must manage the security
features of the drive, perform the password/key management, and
provide a good user experience with a nice familiar-looking UI (hint,
hint).
Finally (at least for "Part 1" or my reply), I'd like to point out
that there is no shortage of software-based snake oil crypto. But
just because software snake oil crypto exists, I'm not going to
declare the "fall of software disk encryption". We all know that
there are reputable companies, such as PGP, who take the security
seriously and do a fine job of implementation. It's no different in
the self-encrypting drive market. There will be snake oil products,
and there will be exceptionally secure products.
Best regards,
Darren Lasko
Principal Engineer
Advanced Development Group, Storage Products
Fujitsu Computer Products of America
"[email protected]" <[email protected]>
Sent by: [email protected]
04/28/2009 04:02 PM
Please respond to
[email protected]
To
[email protected]
cc
Subject
[FDE] [email protected] has shared: The Strange Rise and Fall of Hardware
Disk Encryption
The Strange Rise and Fall of Hardware Disk Encryption
http://blog.pgp.com/index.php/2009/04/the-strange-rise-and-fall-of-...
[email protected] sent this using ShareThis.
_______________________________________________
FDE mailing list
[email protected]
http://www.xml-dev.com/mailman/listinfo/fde
This message contains information which may be confidential and
privileged. Unless you are the addressee (or authorized to receive for the
addressee), you may not use, copy or disclose to anyone the message or any
information contained in the message. If you have received the message in
error, please advise the sender by reply [email], and delete the message.
_______________________________________________
FDE mailing list
[email protected]
http://www.xml-dev.com/mailman/listinfo/fde
