Good cryptography is an excellent and necessary tool for almost anyone. Many good cryptographic products are available commercially, as shareware, or free. However, there are also extremely bad cryptographic products which not only fail to provide security, but also contribute to the many misconceptions and misunderstandings surrounding cryptography and security.

Why “snake oil”? The term is used in many fields to denote something sold without consideration of its quality or its ability to fulfill its vendor’s claims. This term originally applied to elixirs sold in traveling medicine shows. The salesmen would claim their elixir would cure just about any ailment that a potential customer could have. Listening to the claims made by some crypto vendors, “snake oil” is a surprisingly apt name.

The snake-oil-faq is a fun website with a lot of information.Regarding “one-time-pads” it says:

A vendor might claim the system uses a one-time-pad (OTP), which is provably unbreakable.

Snake oil vendors will try to capitalize on the known strength of an OTP. But it is important to understand that any variation in the implementation means that it is not an OTP and has nowhere near the security of an OTP.

What are One-time-pads, and why are they “unbreakable”?

A One-time-pad is a key as long as the message.Each byte of the OTP is generated with an unpredictable random process.

The sender and receiver each need a copy of the OTP and must insure no one else has a copy. The OTP should be physically exchanged, not transmitted.

Each byte of the OTP is only used once – so there is no “statistical pattern” that an adversary could use to crack the message.(More info is at: http://en.wikipedia.org/wiki/One-time_pad.)

The unbreakability of one-time-pads rests on three factors:

1. Every byte in the OTP is generated by a truly random (unpredictable) process.

2. Every byte in the OTP is used only once.

3. The sender and recipient insure that no one else could have a copy of the pad.

When these are true, the OTP is unbreakable – there is no vulnerability that can be exploited.

How Product X works (I think)

Note: This is not a comprehensive evaluation of “Product X”, but rather my personal quick comparison of the information on their website to One-time-pads. Their website does not have a complete technical description, so I’ve made some assumptions that could be inaccurate.

If I understand correctly, “Product X” works like this:

– “Product X” uses a USB device and some software to provide secure authentication (login) from the user’s client system to a remote server.

– The user supplies a User ID and a Password on the client system.

– The User ID is sent to the server software, which selects an “index” that is sent back to the client.

– The “index” and secure information in the USB device create a “one-time password”, claimed to be equivalent to a One-time-pad.

– The “one-time password” is used to securely transmit the User’s password to the server.

Is “Product X” the equivalent of a one-time-pad?

Let’s look at the factors that make one-time-pads unbreakable:

1. Every byte in the OTP is unpredictable.

I will assume they got this right.You can use random.org, or several other techniques.

2. Every byte in the OTP is used only once.

I don’t think this is the case.I believe the “index” sent back from the server, works with the USB device to “randomly” select a pad.If enough logins happen, eventually pads will get re-used.

The Snake Oil website says:

OTPs are seriously vulnerable if you ever reuse a pad. For instance, the NSA’s VENONA project [4], without the benefit of computer assistance, managed to decrypt a series of KGB messages encrypted with faulty pads. It doesn’t take much work to crack a reused pad.

3. The sender and recipient insure that no one else could have a copy of the pad.

I don’t think this is the case.I believe all users share the same set of pads (otherwise the remote server would need a huge amount of per-user data).

However, I believe the role of the USB Device is to scrambles the pad selection on a per-user basis.I think security experts agree – a device like this (assuming well implemented) with a physically secure secret, provides significant security advantages.

So, the strength of “Product X” is based on:

– Could an adversary detect re-use of a pad?

– Could an adversary subvert the secret in the USB device?

This is the point of the “Snake Oil” FAQ.The strength of “Product X” is based on its own implementation details – not the “unbreakable” strength of one-time-pads.

I hope users of “Product X” also understand that it*ONLY* provides special security for the authentication step (the communication of the password).It does not help with the rest of the communication between the client and the server.

Since One-time-pads are so dang secure, why aren’t they used for everything?

OTPs have two important limitations:

– They must not be reused, and need to have as many bytes as the messages they are encoding.This is not practical if you’ve got gigabytes going back and forth every day.

– There must be some other secure mechanism to get the pad from one party to the other.That’s hard to do if you’re communicating with someone you’ve never met before (common on the web).

Red Hat Enterprise Linux 5.2 was released today. That is significant news in and of itself, but I am especially excited because it contains Technology Previews of eCryptfs, TrouSerS, and tpm-tools! As Technology Previews, they are not yet supported for production use, but this is the first step to allow for experimentation and time for ripening. I’m happy to see Red Hat’s continued dedication to security. If you try these packages out in RHEL, I’d love to hear of any successes or problems that you encounter.

Roy Fielding[1] finally quit the OpenSolaris community today, see his resignation letter[2]. The kettle finally boiled over and the realization come to many (but not all) that Sun is publishing their Solaris code for marketing purposes, rather than creating an independent, community-led, open source project with the ability to make real decisions.

It seemed so promising at first: “[T]hey made promises about it being an open development project. … Sun gave up its right to make arbitrary decisions regarding the phrase ‘OpenSolaris’ as part of its public agreement with the community in the form of the Charter. That was a self-imposed restriction in exchange for the benefits of community-driven development, freely made, and cannot be changed except in accordance with the charter itself (for example, by amending or dissolving the charter).” (excerpt from Roy Fielding’s resignation letter) But it was a sham: “The charter has therefore been violated. … Sun agreed that ‘OpenSolaris’ would be governed by the community and yet has refused, in every step along the way, to cede any real control over the software produced or the way it is produced, and continues to make private decisions every day that are later promoted as decisions for this thing we call OpenSolaris.” (excerpt from Roy Fielding’s resignation letter)

To be fair, most developers recognized the community as a sham right away merely based on the copyright and patent assignments required by the contributors agreement[3]. To date, Sun has received 578 patches[4], which represents a rate of 0.6 patches a day (first patch dated 6/17/05, there were some earlier undated contributions). Linus gets more patches while he is brushing his teeth than OpenSolaris gets in a week. Despite Roy’s efforts to build a real community, contributing to OpenSolaris always has been and seemingly always will be, corporate welfare.

For me, the realization that Sun just doesn’t get it, and never will, was crystallized the day I was turned away from an OpenSolaris Users’ Group meeting for refusing to sign an NDA.

It is a credit to the Solaris engineers that a few hearty souls want to soldier on amidst the wreckage: “Nonetheless I believe the time has come for a reboot and I am looking for other like-minded people to stand and form a full Board for positive change.”[5] And others who are even contemplating forking: “We will need to build out our infrastructure so that we can host development, mailing-lists and etc.. Once that is done, we will need to make the case to start moving development to the new organization/infrstructure. This will mean that even Sun employees will have to chose to move their development work to a community ‘controlled’ development infrastructure.”[6] It is to them, that I dedicate the title.

Current and former co-workers, Kent Yoder, Dave Challener, Ryan Catherman, Dave Safford, and Leedert van Doorn have written a book called A Practical Guide to Trusted Computing. It’s now available for pre-order on Amazon and will available on Jan. 7, 2008. The authors have been instrumental in the creation of the TCG specs and key open source software, for example, Dave led the TSS Working Group for years and Leendert was on the Board of Directors. I reviewed an early copy of the book almost exactly a year ago. My favorite parts of the version that I read were the chapters on TSS along with the sample code for how to use the TSS API and the chapter on use cases for Trusted Computing (for the sheer fun of it). I think that it definitely lives up to its billing as a practical guide and it provides a complete grounding in the concepts of trust, attestation, measurement, etc. that are foundational to Trusted Computing. It is very readable and is a faster read and shorter than it seems because of the reference information included. I haven’t yet seen the ultimate version of the book, but I’m eagerly awaiting my copy from Amazon. Congratulations to the authors for sticking through the long haul and providing such a useful book!

The NSA has published their Guide to the Secure Configuration of Red Hat Enterprise Linux 5[1]. This is an excellent document that describes best practices for securing a Linux system – tailored to Red Hat Enterprise Linux 5. It starts with best practices, such as, encrypt transmitted data and minimize installed software. It then follows up with exact configuration recommendations, for example, the exact configuration option to prevent root from logging in directly via ssh (Section 3.5.2.6). They do a pretty good job describing the rationale for making the changes that they recommend (“The root user should never be allowed to login directly over a network, as this both reduces auditable information about who ran privileged commands on the system and allows direct attack attempts on root’s password.”). If you are responsible for the security of any Linux system (whether as a developer or an administrator), I highly recommend taking a look at this document and thinking twice about any decision that you make that runs counter to these recommendations.

[1] http://www.nsa.gov/snac/downloads_redhat.cfm?MenuID=scg10.3.1.1

EDIT 4/21/2009: updated a corruption that rendered the ‘ in the word root’s incorrect
The new location for the guide is http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf

According to HP Backs Red Hat in Government Biz Bid [1], “Lillestolen said, however, that HP has gone further than Big Blue by certifying a wider range of hardware.” Hopefully, this is just a mistake in the reporting and HP isn’t actually making such outrageous claims. As you can see in the Validation Report [2], HP tested on

In both cases, 8 different machines were tested. However, IBM tested radically different architectures, whereas HP tested minor variations of a few themes. For those of you not familiar with IBM terminology, the IBM evaluation tested a mainframe, a POWER system, a POWER blade, a rack-mounted Opteron system and Opteron blade, two Intel Xeon blades, and a rack mounted, dual-core Intel Xeon server. For those unfamiliar with HP’s line of hardware as I am, their website shows that HP tested one desktop and 3 rack-mountable Intel Xeon systems, three rack-mountable Opteron systems, and two rack-mountable Itanium systems. None of the systems listed in their Validation Report is a laptop contrary to Lillestolen’s claim.

I am glad to see that RHEL5 has received so much testing in the MLS configuration. Perhaps widespread knowledge that many systems were tested in many configurations will help speed the adoption of the MLS configuration in the defense industry. But I hope that reporters won’t let HP get away with making such wild statements that are easily refutable via on-line documents.

As a security practitioner, you’ve got to love it when your company comes out with a line like “Security is our brand” [1] and the press eats it up. Of course, security has always been our brand and, on the Open Source side, we have done some significant things to prove it. I’m speaking here of our multi-million dollar investment over the course of many years to Common Criteria certify Red Hat and Novell SUSE. We started out at EAL2 with the security functionality defined in our Security Target against the pre-existing security functionality in SLES 8. We got that evaluation done within 6 months when everybody was saying that it couldn’t be done – ‘Common Criteria certification takes years’, ‘open source can’t be certified’ they said. From that ground work, we marched up the value chain to LSPP/RBACPP/CAPP at EAL4+ with RHEL5 when still (after 6 successful evaluations at progressive levels) people were saying that it couldn’t be done (although much more subtly now) – “The lack of this protection might prevent another evaluation target from passing this evaluation.” [2]

Our LSPP evaluation included more hardware platforms in one evaluation (7) than all previous completed LSPP certifications combined. The beauty of the range of platforms certified is that it allows government agencies who need LSPP to also take advantage of the scale-up and scale-out capabilities inherent in Linux. As a tax payer, I love this because it allows government agencies to benefit from the lower TCO that Linux and open source software provide.

The LSPP evaluation, in my eyes, constitutes a revalidation of the open source development methodology because the project included competing and cooperating companies, along with government, distro, and individual contributors who were contributing as a labor of love and because they believe in the necessity of adding this level of security to Linux.

When we completed the LSPP evaluation, I went back and looked at all of the people who had contributed to the Common Criteria certification effort over the years. Just within IBM, the number went into the high double digits. Of course, none of this would have been possible without the dedication and passion for security shown by Novell and Red Hat. And our evaluator was invaluable – the insight, integrity and sheer brilliance of the people working for atsec is without measure or compare.

This press item has been picked up all over the place – IBM announces an initiative to invest $1.5B in security development and marketing for 2008. This is seriously cool.

Very interesting quotes from IBM executive Val Rahmani:
“‘We believe there’s a crisis in the marketplace right now,’ said Val Rahmani, who heads IBM’s infrastructure management services.” from NYTimes at http://www.nytimes.com/aponline/technology/AP-IBM-Security.html?_r=1&oref=slogin

“‘Security is broken,” Val Rahmani, general manager of IBM’s infrastructure management services, said in a telephone interview. ‘There has been a perfect storm of threats.”’ from http://www.bloomberg.com/apps/news?pid=20601204&sid=a6ohOhxgElJ0&refer=technology

Author: Emily Ratliff | Posted on 1. November 2007 at 16:03 pm | Filed in Products | Comments Off on IBM to spend $1.5B on security development in 2008

The Register has a story Root-locked Linux for the Masses[1] that I’m finding almost unreadable because in the first sentence, the project originator has overloaded by the acronym TCP and the term Trusted Computing. I find it supremely amusing that someone would start a new project called the Trusted Computing Project, which has absolutely nothing to do with Trusted Computing – talk about starting from a deficit.