Slashdot Mirror
Cryptographic Security Architecture
Cryptographic Security Architecture is a technical book that focuses on security architectures, verification techniques, and cryptographic software and hardware. It is an excellent reference source that intricately captures the design process of a security toolkit that has been in use for several years across the globe. The security architecture presented in the book is platform-independent, but the book does touch on platform-specific issues when necessary, especially when cryptlib implementation details are described. The toolkit has been ported to a slew of platforms.
Even though the book and the toolkit benefit from each other's companionship, both can certainly stand alone. The reader doesn't have to be familiar with or even interested in cryptlib to gain from reading Cryptographic Security Architecture . In this review of the book I will keep toolkit discussion to a minimum. The semi-GPL cryptlib security toolkit is OSI-certified open source. The security toolkit includes an excellent user manual which is a formidable 310 pages.
The Passion of the Cryptographic Security Architecture
Cryptographic Security Architecture's first chapter covers the foundational software architecture and is a bit dull. I would hope that the target audience is familiar with basic subjects like object-oriented design and inter-object communications. Too much attention is given to what should have been prerequisite knowledge at the expense of security related matter. For instance, while Gutmann gives a lot of attention to basic object synchronisation (the Kiwi spelling, which is suitably preferred by him) he only alludes to a class of security issues involved with multi-threading. If you can make it through the first chapter, rest assured that Gutmann avoids this flaw in the rest of the book. To be fair, this back-to-basics review does well at underpinning the rest of the security architecture, even though it often reads like a software architecture primer.
The second chapter covers the security architecture, which features such things as permission-based access, least privilege and isolation, mediation, and other expected elements. The design goals include some common goals, like simplicity and efficient implementation. But three of the design goals represent the core philosophy of Gutmann's architecture: The separation of policy definition and enforcement mechanism, a verifiable design (practical vs. theoretical viability), and a flexible security policy.
The separation of the policy definition from the enforcement mechanism solves problems that exist in previous attempts at security architecture (e.g. some Orange Book-based systems hardcode the policy). One claimed benefit of separation is the reduction of complexity in the enforcement mechanism and the improved verifiability that simplicity brings. But I would argue that complexity has been shifted from the toolkit to the toolkit user, who can opt to configure their specialized security policy. What mechanism is going to be used to verify these user-defined policies? It's unlikely the toolkit user's policy will receive the scrutiny that the open source community bestows upon the factory bits.
But I may not fully understand the capabilities of the security policy scheme. Perhaps, when using Gutmann's cryptlib, it is impossible for the toolkit user to configure an incoherent policy. In George Orwell's 1984, the Party worked to deconstruct the English language so that only 'legal' speech could occur. As designed, Newspeak would make illegal statements unspeakable --- and in time, unthinkable. I'm unconvinced that Gutmann's security policy scheme is such a controlled means of expression, where only safe security policies can be spoken. Granted, one could always use the predefined policies, but this path undermines a chief design goal of the architecture: a flexible security policy.
Notwithstanding my nitpicking about the policy, the security architecture chapter is a good example of how the book shines. Gutmann covers in detail his design process and chocks the chapter full of references for the reader's further study. In all, there are almost 700 reference listings, which consume 15% of the book's 320 pages.
The policy definition scheme is followed by a detailed discussion of the security kernel implementation. (The kernel is the policy enforcement mechanism, referred to earlier.) Like most of the book, the writing is as dense as most detailed architectural designs and sometimes sleep-inducing. But Gutmann's writing style is clear, concise, and sometimes funny. Gutmann's writing talent makes even descriptions of "Access Control List for public-key/certificate access" and "Access Control List for an attribute that triggers an object state change" endurable.
Verification techniques for the security architecture are a major theme of the book. Anyone who has attempted to verify that software does what it was specified to do, especially in the security field, will find Gutmann's insights worthwhile reading. This is especially true for anyone who has ever done a Common Criteria-based evaluation, or a verification employing any of its ilk. Gutmann makes an excellent point about the semantic pitfalls of formal methods: "As with ISO 9000, it's possible to produce an arbitrarily bad product but still claim it's correct, since it complies with the paperwork."
Cryptographic Security Architecture also contains the obligatory chapter on random number generation. The chapter includes more of Gutmann's trademark insights. He discusses many software and hardware implementations, including the generators contained in: PGP (Pretty Good Privacy), /dev/random, ssh, Capstone / Fortezza, Intel Pentium III, Microsoft's CryptoAPI, cryptlib, and others. Random number generation flaws abound. For example, he discusses the flaws in the ssh and SSLeay/OpenSSL generators that make it possible to "...suck infinite amounts of state information out of [the random number generators] by repeatedly connecting to the server..."
Towards the end of the book, Gutmann includes a dessert-like discussion of hardware encryption modules. Gutmann's predilection for security hardware is evident as he writes about problems with crypto on end-user systems. This chapter includes all sorts of cryptographic hardware including the designed-for-hostile-environments HiDan embedded PC. One interesting technique to secure modules like the HiDan is to pour a hardening material (e.g. epoxy) into the chamber before sealing it shut.
Regarding the book's construction, while the references are excellent, the glossary and index are poor. Even if you rely on external sources for acronyms, as the author suggests, some of his acronyms are not included in the glossary. For instance, it took me awhile to determine that CMP stood for Certificate Mismanagement Protocol. The index is also oddly incomplete, considering Gutmann's otherwise good documentation habits.
Conclusion I expected Cryptographic Security Architecture to treat the topic of security architecture in a general way, offering many alternatives for designers to ponder while designing their own security architecture. The book does this, but often Gutmann whittles down the prudent design options to one, with most paths arriving at a single destination, namely Gutmann's cryptlib. Don't get me wrong: It's good to be decisive when faced with many architectural tradeoffs, and the ugly alternative is all too often design paralysis. And it's no surprise that cryptlib, according to Gutmann, contains the best architectural elements - he is the author of both the book and the toolkit. Still, the homage to cryptlib often made me unsure that a wide spectrum of design options had been considered: Did the security architecture spawn the cryptlib implementation, or did the implementation spawn the architecture?To be clear, the strong points of the book (and concepts therein) far outnumber the weak ones, and I highly recommend it to anyone interested in security architectures, verification techniques, and cryptographic software and hardware in general. Simply put, the book is excellent and it should expand most reader's knowledge of cryptographic security.
You can purchase Cryptographic Security Architecture: Design and Verification from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Relying on secret design to ensure security is what is known as seucrity through obscurity and is generally frowned upon by the security community the first thing you do when designing a secure system is assume that the attacker knows exactly how it is set up. In the case of ATMs if one designs the security around the attacker not knowing the design what happens when an ex-employee decides to make a quick buck?
Actually there are stories of ATMs being cracked into, since ATMs invariably run on some kind of operating system. And yes, I get that it's just an example.
However, to answer your question, the reason security concepts are being opened to the public is mainly because they have to be standardized rather than oligopolized. This allows the security concepts (like RSA algorithms, DES, Blowfish, PKI) to be used on various platforms with various tools. If it were closed, or discreet, it would be even more inconvenient for people to use, and thus people would be less likely to use it, thus rendering it useless.
exactly - in fact suppose I want to hack into an ATM - if I'm bright I'll certainly look at the open source ATM code ... and if it is indeed well designed and protected by lots of lovelly large primes that I don't know I'll probably look elsewhere. On the other hand Diebold's recent voting machine snafu's would probably have me looking long and hard at any ATM they make (or in my case be looking for a different bank to put my money in should my bank start using them)
The funny thing is that Cryptlib is supposedly GPL, but it contains cryptography code by Eric Young (author of the original ssleay that became OpenSSL). Eric Young's code has an advertising clause. Hence, some of the code in the supposedly GPL'd cryptlib violates the GPL.
For what it's worth, LTC is a fantastically architected crypto library. The utter simplicity of what Tom puts together is disarming, compared to the utter horror that ships with (say) OpenSSL. Both Dropbear (a very small SSH server) and MatrixSSL (a very small SSL server) have been built on LTC.
Plus, you get a crypto lib with Makefile.gba. That's Gameboy Advance. Yup.
--Dan
Before using libtomcrypt, read Tom St. Denis' postings to sci.crypt on various topics.
Perhaps an immature wanker who flames in 3 out of 5 of his posts can write a really solid crypto library. Why bother, though, when there are solid libraries that already exist and you don't have to deal with the preening little 19 year old?
If some mathematician creates an easy way to factor large numbers (and they have been finding better and better ways to do this), then systems like RSA become vulnerable even if they use umpteen bits.
In fact, if the factoring is sufficiently efficient the whole system comes to bits. Yes you can just double the key size to make it unfactorable, but you can only do that so many times before
(1) The key gets so large that it is hard to manage (this is certainly at the upper end, but large keys can be problematic).
(2) The key gets so large that the encryption process is too slow (faster computers mean faster encryption, but also faster cracking).
Oddly enough, there are upper bounds on key size, as well as the lower bounds provided by how easily the problem can be solved. Once these bounds overlap, the system is effectively compromised.
Jedidiah
Craft Beer Programming T-shirts
Other crypto resources.
OK, I admit it I just wanted to use Google Sets for something.
"One interesting technique to secure modules like the HiDan is to pour a hardening material (e.g. epoxy) into the chamber before sealing it shut."
;)
Solving abstract problems with implemented ideas first??? Shame on you sir...
0.) post so late, no one will ever see this
1.) Epoxy potting compounds are NOT SECURE and only add to design and calibration problems during manufacture. See 1980's...
2.) Hardware Data encryption? Only possible with embedded recursive encryption algorithms that are dependent on unique internal protected key registers.
3.) Embedded security? If you mean Harvard architecture that's immune to overflows will prevent a privileged User from doing something stupid... lol
4.) Hardware communication security? Any discriminating algorithm must have a probable solution. However, the most secure systems I've seen use high speed synchronized internal clock offsets (not possible for satellite comm. For obvious reasons) and polymorphic encryption modules that mutate when exchanged between two nodes.
5.) Wireless comm.? Antenna-load-sensitive auto-adapting scatter-band UHF SAW based comm.
Hardware and software will always be vulnerable. Any programmer can tell you that Users never do what they are expected to do. Any hardware designer can tell you people rarely know what they want, never alone what the consumer will actually need or tolerate