Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

Cryptographic Security Architecture 134

Posted by timothy from the trust-but-verify dept.
imaginaryNumber writes "Peter Gutmann distinguishes his renowned cryptographic library, cryptlib, from other security toolkits available by claiming it provides a 'coherent security model' that other toolkits omit. His criticism goes further to say that some security toolkits 'lack real security features altogether.' It comes as no surprise, then, that his recent book, Cryptographic Security Architecture: Design and Verification, is a 320-page paean documenting the coherence and the sure-footed construction of his security toolkit. I am a student of electronic privacy, cryptography, security, and mathematics, and I am an admirer of Peter Gutmann's work. He is prolific in the security field, and Gutmann's website at the University of Auckland is a good introduction to his work. I had the pleasure of meeting him recently in New Zealand, after he agreed to field some questions about his book. As you will read in my review, I highly recommend the book even though it has a handful of flaws. And while I have a great deal of respect for the author's work, I'm not ready to accept all of his ideas as gospel." Read on for the rest of imaginaryNumber's review.
Cryptographic Security Architecture: Design and Verification
author Peter Gutmann
pages 320
publisher Springer-Verlag
rating 8
reviewer imaginaryNumber
ISBN 0387953876
summary A technical book about security architectures, verification techniques, and cryptographic software and hardware

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.
This discussion has been archived. No new comments can be posted.

Cryptographic Security Architecture More

Cryptographic Security Architecture

Comments Filter:

  • An interesting crypto library (Score:4, Informative)

    by WilliamsDA ( 567274 ) <derk AT derk DOT org> on Monday March 29, 2004 @05:20PM (#8707669) Homepage
    Tom St. Denis has a nice crypto library at libtomcrypt.org [libtomcrypt.org]. I like it, anyway.. it's worth a look :)

    • Re:An interesting crypto library (Score:2, Funny)

      by Anonymous Coward
      Dude! I just ran strings on it! Look:

      _DYNAMIC
      _GLOBAL_OFFSET_TABLE_
      __gmon_s tart__
      _fini
      __cxa_finalize
      _Jv_RegisterClasse s
      CRYPTO_get_new_lockid
      sk_new_null
      BUF_strdup
      sk_push
      CRYPTO_free
      ERR_put_error
      CRYPTO_num_lo cks
      CRYPTO_get_new_dynlockid
      CRYPTO_lock
      CRYPTO _malloc
      sk_find
      CRYPTO_destroy_dynlockid
      Screw it, this hard, Just ROT13 everything
      ....

    • Ain't kidding (Score:3, Interesting)

      by Effugas ( 2378 )
      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

    • Re:An interesting crypto library (Score:2, Interesting)

      by Anonymous Coward
      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?
      • Exactly my point! Stop using my library ya thieves!!!

        To nitpick though I'm a "preening little 21.99 yr old". I have been 19 since I was 19.

      • I read sci.crypt regularly, even if I don't post there. Granted, Tom comes forward as someone who has certain attitude problems (yes, I'm willing to go on record saying this) but the library is still a marvelous piece of work. It's not like we haven't seen controversial [cr.yp.to] personalities in this field before. Also, LTC is nothing but a simple building block, and you can actually verify its functionality and integrity by running the algorithms against any known and verifiable test vector sets. (Locating these is

  • Who worries about security these days anyway? (Score:1, Funny)

    by Anonymous Coward
    It's too much of a hassle at the computer level. You just need a guy checking the door at your work. We pay a high school kid (part timer) and it's been great for us.

    I fail to see how this "cryptography" is anything more than another attempt at making nerds seem valuable. Self-promoting sons of bitches gonna get swirlies if they cross my path.

  • Paean (Score:5, Funny)

    by Anonymous Coward on Monday March 29, 2004 @05:22PM (#8707694)
    Had to look it up. Now I will never be quite sure if some is saying 'A pain in the ass' or a 'A paean in the ass'. They mean very different things.

    • Re:Paean (yes it is funny) (Score:5, Informative)

      by fishybell ( 516991 ) <fishybell.hotmail@com> on Monday March 29, 2004 @05:47PM (#8707963) Homepage Journal
      For all of those moderators out there that are unaware, the above post is indeed funny.

      From Dictionary.com:

      paean also pean
      n.

      1. A song of joyful praise or exultation.
      2. A fervent expression of joy or praise: "The art... was a paean to paganism" (Will Durant).
      3. An ancient Greek hymn of thanksgiving or invocation, especially to Apollo.

      So "A paean in the ass" or "A [fervent expression of joy] in the ass" is indeed very different from "a pain in the ass."
      • So "A paean in the ass" or "A [fervent expression of joy] in the ass" is indeed very different from "a pain in the ass."

        Of course, the one could lead to the other.
      • For all of those moderators out there that are unaware, the above post is indeed funny.

        No offence meant, but this made me chuckle. It's the star trek approach to humour: "the computer has analyzed your claim and detected a trace of sarcasm. this is entirely illogical. capt. kirk will now beat the sh*t out of you."
        I'm not so sure that whether something is funny is something that research and analysis uncovers...

  • quick synopsis (Score:4, Informative)

    by spangineer ( 764167 ) on Monday March 29, 2004 @05:27PM (#8707747) Homepage
    Quick synopsis of the book [amazon.com] (if you don't have time to read the whole review):

    "A cryptographic security architecture constitutes the collection of hardware and software that protects encryption keys and other related security parameters from misuse. If the process used to generate the cryptographic code is insecure then even the most sophisticated protection mechanics will not do any good. This topic is extremely important, especially for "embedded"-hardware products and services like smart cards. The author offers a novel design that allows for a great deal of customization."

  • Encryption / circumvention (Score:1, Insightful)

    by Anonymous Coward
    Looks to be a good book. I'm planning on getting a copy ASAP ... no doubt the DMCA will censor this book (it has provisions against crypto technology) before too long. In these times of censorship and technological tyranning, I feel sad to be an American :-(

  • Cryptlib contains code that violates GPL (Score:4, Interesting)

    by Puzzleer ( 309198 ) on Monday March 29, 2004 @05:48PM (#8707969)
    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.

  • Self Promotion, and Incoherent Policies (Score:5, Insightful)

    by Sensitive Claude ( 709959 ) on Monday March 29, 2004 @05:59PM (#8708047) Homepage Journal
    His criticism goes further to say that some security toolkits 'lack real security features altogether.' It comes as no surprise, then, that his recent book... is a 320-page paean documenting... his (own) security toolkit.

    Wouldn't it be more helpful, not to mention better motivation to purchase his own security toolkit, if he were to go into more detail of what is wrong with other toolkits than just saying they 'lack real security features altogether.'

    Why not write a short critique of other toolkits, ideally explaing advantages and disadvantages each one has..... or is this not supposed to be a book on Security in general, but just documentation on his own toolkit?

    I suppose even if you don't want to buy his toolkit you can get ideas from reading about it.

    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.

    Problem with this is that Managment who don't understand the software are often making the decisions, and that is why there are incoherent policies. Maybe if you have pre-defined policies to work with, all of which will work, then Management can choose from the pre-defined policy, resulting in much less hair pulling frustration to the admin.
    • Wouldn't it be more helpful, not to mention better motivation to purchase his own security toolkit...

      Cryptlib is GPL'd, although you can buy a commercial license as well. But you don't have to pay anything if you are using it in a GPL project.

      Another thing not noted in the review, the book is actually Peter's PhD thesis. It's pretty technical; I looked through a draft at a crypto conference. I don't think it would be of interest other than to the kind of person who might be wanting to implement a crypt
    • The book may be flawed in that it doesn't look at other toolkits, but I don't think that his motivation is to sell cryptlib, which is available "under the GPL-compatible Sleepycat [sleepycat.com] dual license, which means you can use it under the GPL terms or under standard commercial terms, depending on your preference." [http://www.cs.auckland.ac.nz/~pgut001/]

    • Hi, just jumping in as someone who does this for a living. I doubt that Gutmann could make any sane statements of policy. He clearly thinks his libs are great, as I would expect. Wouldn't you? Policy means asking about your environment. What do you need? how much do you lose if you don't hit your security targets? What does your enterprise lose if you're exposed? Hell, what is exposure? As far as policy goes... sorry, security is not a thing you buy, it is a behaviour. You _do_ have it or not, but it does

  • Crypto only as safe as the math under it (Score:5, Informative)

    by G4from128k ( 686170 ) on Monday March 29, 2004 @06:00PM (#8708051)
    Having not read this book, I don't know if the author addresses the issue, but one key potential weakness in many crypto systems is the math at the core of them. Although the difficulating in cracking many crypto systems scales exponentially with the number of bits in the key, no one can gaurantee that a given size key is intractable. The formula for the time required is a*b^N, but nobody can gaurantee that a and b aren't small numbers.

    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. Any math-based crypto system faces this challenge. Ironically, the strength of the system is, in part, based on the weakness of out understand of the math. Unless someone can prove that a lower bounds exists, the system is of unknown uncrackability.
    • 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 proble

    • Well, now... (Score:3, Insightful)

      by Kjella ( 173770 )
      Having not read this book, I don't know if the author addresses the issue, but one key potential weakness in many crypto systems is the math at the core of them.

      Symmetric cryptography hardly suffers from any weakness in this area. Even an instant factorization or quantum computing would do little to change that.

      Public cryptography on the other hand, must by definition rely on some mathematical relationship between the public and private key. Like e.g.multiplicationfactorization, but that is not the only
      • Now you invent a new O(N*ln N) factorization, or an O(N). Does it matter? Not really. You need a longer key, yes. But it's a finite improvement. Unless they can find a O(1) factorization, the system still works. And that, is very unlikely.

        I don't quite have the time to refute this in depth, but this is completely wrong. Security of cyphers based on prime factorization depends on this operation being a very hard problem. A O(N) or O(N*ln N) (or even N^2 or N^p for smallish values of p) algorithm would m
    • Well in a way that is not really intersting for a crypto person, only a mathematician. A crypto person need only know what a given class of algorithims do, whether they are currently known to be unbreakable, and then use the right one appropiately.

      I have a very basic understanding of crypto, so for example I know what a secure hashing algorithim does, but I may be tempted to use it for a hash where the reverse transform is not actually important, but where some properties of a hash like that may actually i
  • I'm not a number theorist. I don't have the time to audit every line of code (even if it's open source) in a library.

    So how can I trust anybody's crypto code?

    • Re:So what the heck do I do? (Score:2, Funny)

      by Anonymous Coward

      Hello, I'm from Microsoft and I'm here to help you.

    • Um no. Everyone is out to get you specifically.
      • If only I were that worthy of being targetted...
        • Step 1. Be generous and give something out.

          Step 2. Sit back and watch people flame you for no reason other than they wish they had a 1/100th of your talent.

          Step 3. Laugh all the way to the corner store where you will work the rest of your life living in a van down by the fucking river!
          • Tom I hope that isn't completely autobiographical. Part 1. and 2. are true. If part 3. is true, then you truly are "suffering for your art". Hang in there.
            • So far I don't have a van so that part of #3 doesn't look likely.

              As for "suffering for my art" I'd like to think I'm more humble than that. Sure I contributed stuff but it wasn't earth shattering can't live without. I helped a few people. That's what I was looking for [and maybe a job down the line].

              See I don't "work/think" like the average person. I can't live in the world where you basically have to lie to your customers because everyone else does it. This is how it started... nice warm day in the
    • I'm not a number theorist. I don't have the time to audit every line of code (even if it's open source) in a library.

      So how can I trust anybody's crypto code?

      You presume that as long as the code is openly published, and at least somewhat widely used, that there are number theorists and crypto experts picking through it. As far as popular open crypto code goes, that is certainly true.

      That's not to say people couldn't slip a backdoor in, but if you're publishing your code openly, there's always a chance
    • Try reading Practical Cryptography by Niels Ferguson and Bruce Schneier.

      Good security is much more about implementation than number theory. A good cypher is very hard to break. Will a smart attacker, attack the cypher which is very hard to break or some implementation mistake which is probably much easier to exploit?
    • The answer is that you cannot trust anybody's crypto code. Remember that it is always worse than you think and THEY are out to get you.

  • Working on it... (Score:5, Informative)

    by Coryoth ( 254751 ) on Monday March 29, 2004 @06:17PM (#8708236) Homepage Journal
    The second chapter covers the security architecture, which features such things as permission-based access, least privilege and isolation, mediation, and other expected elements. ... 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.

    It is worth noting that this is exactly what SELinux from the NSA was seeking to apply to Linux at a kernel level. The principle is to confine all user programs and system daemons to an absolute minimum required level of access. That is there is an access manager in the kernel that mediates requests. In turn, there is a policy manager (seperate from the access manager) that maintains policy. Effectively the access manager queries the policy manager and then applies whatever access decision the policy manager returns. This means buffer overflows don't get you anywhere - there is no root account with universal access to exploit!

    The system is, in fact, even more flexible than that - seperate access managers exist for processes, filesystem access, and IPC (socket or System V), but the hooks are provided in a way that this is completely modular, and new access managers can be added/written for whatever else you want to control (database access for instance).

    The point is, a very fine, well thought out, secure system for access conrol has already been implemented for Linux (and has been folded into the 2.6 kernel). People ought to be using it! If you're running a 2.6 kernel, see if you've got LSM compiled in, if not, do a recompile to include it. Example policies can be found here [nsa.gov], and policy management tools (even GUI ones) can be found here [tresys.com]. If you're serious about security, the you ought to to be using this stuff. If you're not serious about security, use it anyway and help make Linux as secure as we like to pretend it is.

    Jedidiah.

  • Other crypto resources (Score:3, Interesting)

    by hey ( 83763 ) on Monday March 29, 2004 @06:36PM (#8708446) Journal
    Other crypto resources [google.com].
    OK, I admit it I just wanted to use Google Sets for something.

  • Crypto++ (Score:1)

    by Josh ( 2625 )
    I don't believe that any software library is anything like a security architecture.

    But when I looked around 2 years ago for the best crypto library to actually write code with, I settled on Wei Dai's Crypto++

    http://www.eskimo.com/~weidai/cryptlib.html
  • "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 uniqu

Slashdot Top Deals

Intel CPUs are not defective, they just act that way. -- Henry Spencer

Close