Re: disks with hardware FDE
Perry E. Metzger wrote: There are now a number of drives on the market advertising AES based FDE in hardware, and a number of laptops available on the market that claim to support them. Has anyone had any real-world experience with these yet? Are there standards for how they get the keys from the BIOS or OS? (I'm interested in how they deal with zeroization on sleep and such.) Lastly, anyone have any idea of whether the manufacturers are doing the encryption correctly or not? Perry, I have copied the IEEE 1619.3 Working Group where disk-drive manufacturers are working on some of these KM issues. There is a debate going on on that list about the value of encrypting data at the disk-drive layer vs. encrypting at the application layer - I believe the latter is a more strategic solution - and the voices from the Crypto forum would be welcome on these issues. I will let the FDE vendors respond to you so you can forward as appropriate. Thanks. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: The wisdom of the ill informed
Ivan Krsti? wrote: On Jul 1, 2008, at 12:46 PM, Perry E. Metzger wrote: My experience with European banks is quite limited -- my consulting practice is pretty much US centric. My general understanding, however, is that they are doing better, not worse, with login security. As a data point, the largest bank in Croatia used to mail customers pre-printed TAN lists. Some number of years ago, they switched to (non-SecurID) tokens which require a 4-digit PIN to turn on, and then provide two functions: a login OTP and a challenge/response system for authorizing individual transactions. Your username is simply the token's serial number, though it's not clear if these are in fact serial. Barclay's Bank in the UK uses little chip&pin machines you put your debit card into and provide the same functions as Ivan describes above. I have a spare one I've been meaning to dissect to see what's inside them. I wonder where I put it? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Strength in Complexity?
Arshad Noor wrote: Ben Laurie wrote: Arshad Noor wrote: I may be a little naive, but can a protocol itself enforce proper key-management? I can certainly see it facilitating the required discipline, but I can't see how a protocol alone can enforce it. I find the question difficult to understand. Before I could even begin to answer, you'd have to define what "proper key management" actually is. I consider KM to be the discipline of defining policy and establishing procedures & infrastructure for the generation, use, escrow, recovery and destruction of cryptographic keys, in conformance with the defined policies. Then I would agree that a protocol alone could not achieve all of this, though obviously it is possible to design a protocol that makes it impossible. That said, EKMI (from my brief reading) has a view of key management that is only "proper" in quite constrained circumstances. In particular, keys are available to participants other than those who are communicating, which is general considered to be a very bad idea. I'm not sure I'm following your comment here, Ben. Did some word get left out? In EKMI, keys are available only to those who are known to the central Symmetric Key Services (SKS) server, and who are authorized to receive keys. The "knowledge" comes from entries in the SKS server about the clients and their digital certificates. The authorization comes from ACLs and from policies that apply to the client. OK, so you still have a PKI problem, in that you have to issue and manage client certificates. How is this done? > So, yes, EKMIs are designed for constrained environments. The design paradigm we chose for EKMI was to have: 1) the centralized server be the focal point for defining policy; 2) the protocol carry the payload with its corresponding policy; 3) and the client library enforce the policy on client devices; Well. You said "centralized server". Many cryptographic systems don't have one of those. I realizecd that two years ago when I started defining the architecture for EKMI and the software to implement it. It was the only logical way of addressing the business problem of managing encryption keys for five different platforms/applications that needed to share ciphertext on a daily basis across hundreds of locations and thousands of POS registers. I'd be very surprised if it were the _only_ logical way to do it. But that aside, my point stands: these characteristics are not shared by all cryptographic systems. In fact, I'd say that all of them are not shared by most cryptographic systems. Also, the idea of a client library enforcing policy is DRM all over again. Which, as we all know, will never work. You make an interesting point here. While, conceptually, EKMI and DRM share similar designs, I believe the reasons for DRM's failure has more to do with philosophy than with technology. But that's a different debate. I do not believe this is the case. DRM fails because the attacker has physical possession of the system he is attacking. The fact that the attackers is highly motivated because of the objectionable nature of DRM does not seem to differ much from your system, though in your case the motivator will presumably be profit. P.S. Companies deploying an EKMI must have an external process in place to ensure their applications are using "verified" libraries on the client devices, so their polices are not subverted. Ha ha. Like that's going to work. Even if we assume that libraries are verified (fat chance, IMO), how are you going to stop, for example, cut'n'paste? Employees reading things out over the phone? Bugs? Etc. EKMI's goals are not to provide bullet-proof security. It has more modest ambitions - to provide a management framework for incremental security, targeted at the right resource: the data, rather than the network. Are there any even vaguely modern systems that target the network for security, or is this a straw man? > As such, it will merely be a tool in the evolution towards more secure systems - how people use the tool is up to them. If it is up to them, then why bother with this verification process? This sounds like yet more security theatre to me. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: disks with hardware FDE
Dries Schellekens <[EMAIL PROTECTED]> writes: > Perry E. Metzger wrote: > >> Has anyone had any real-world experience with these yet? Are there >> standards for how they get the keys from the BIOS or OS? (I'm >> interested in how they deal with zeroization on sleep and such.) > > Most manufacturer (will) implement the TCG Storage Specification: > https://www.trustedcomputinggroup.org/groups/storage/ > >> Lastly, anyone have any idea of whether the manufacturers are doing >> the encryption correctly or not? > > I know that Seagate Secure does not use XTS mode, but something CBC based. Where do they get their IVs from? In general, I feel like the only way to really verify that these things are being done correctly is to be able (in software) to read the ciphertext and verify that it is encrypted with the right key in the right mode. The small amount I've heard about the design leads me to worry that this is not actually possible. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Permanent Privacy - Snake Oil or unbreakable encryption?
> This reads like snake oil. >> http://www.foxbusiness.com/story/hackers-hell-privacy-compromised/ > This reads like a pump'n'dump stock scam. zdnet tries to expose the snake-oil crypto and the pump'n'dump stock scam: http://blogs.zdnet.com/security/?p=1448 good start. but i think they could have done better.. saqib http://doctrina.wordpress.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
REVIEW: "The dotCrime Manifesto", Phillip Hallam-Baker (was Re: [RISKS] Risks Digest 25.22))
On Jul 8, 2008, at 2:21 PM, RISKS List Owner wrote: Date: Thu, 03 Jul 2008 11:06:12 -0800 From: Rob Slade <[EMAIL PROTECTED]> Subject: REVIEW: "The dotCrime Manifesto", Phillip Hallam-Baker BKDCRMNF.RVW 20080317 "The dotCrime Manifesto", Phillip Hallam-Baker, 2008, 0-321-50358-9, U$29.99/C$32.99 %A Phillip Hallam-Baker dotcrimemanifesto.com [EMAIL PROTECTED] %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2008 %G 978-0-321-50358-9 0-321-50358-9 %I Addison-Wesley Publishing Co. %O U$29.99/C$32.99 416-447-5101 fax: 416-443-0948 800-822-6339 %O http://www.amazon.com/exec/obidos/ASIN/0321503589/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0321503589/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0321503589/robsladesin03-20 %O Audience n+ Tech 2 Writing 2 (see revfaq.htm for explanation) %P 415 p. %T "The dotCrime Manifesto: How to Stop Internet Crime" In the preface, the author notes that network and computer crime is a matter of people, not of technology. However, he also notes that changes to the network infrastructure, as well as improvements in accountability, would assist in reducing user risk on the net. Section one enlarges on the theme that people are more important than machines or protocols. Chapter one looks at the motive for Internet crime (money, just like non-computer crime), and repeats the motifs of the preface. The text goes on to list various categories and examples of network fraud. The content of chapter two is very interesting, but it is hard to find a central thread. Overall it appears to be saying that computer criminals are not the masterminds implied by media portrayals, but that the problem of malfeasance is growing and needs to be seriously addressed. What Hallam-Baker seems to mean by "Learning from Mistakes," in chapter three, is that security professionals often rely too much on general principles, rather than accepting a functional, if imperfect, solution that reduces the severity of the problem. Chapter four presents the standard (if you'll pardon the expression) discussion of change and the acceptance of new technologies. A process for driving change designed to improve the Internet infrastructure is proposed in chapter five. Section two examines ways to address some of the major network crime risks. Chapter six notes the problems with many common means of handling spam. SenderID and SPF is promoted in chapter seven (without expanding the acronym to Sender Policy Framework anywhere in the book that I could find). Phishing, and protection against it, is discussed in chapter eight. Chapter nine is supposed to deal with botnets, but concentrates on trojans and firewalls (although I was glad to see a mention of "reverse firewalls," or egress scanning, which is too often neglected). Section three details the security tools of cryptography and trust. Chapter ten outlines some history and concepts of cryptography. Trust, in chapter eleven, is confined to the need for aspects of public key infrastructure (PKI). Section four presents thoughts on accountability. Secure transport, in chapter twelve, starts with thoughts on SSL (Secure Sockets Layer), and then moves to more characteristics of certificates and the Extended Verification certificates. (The promotion of Verisign, infrequent and somewhat amusing in the earlier chapters is, by this point in the book, becoming increasingly annoying. The author is also starting to make more subjective assertions, such as boosting the trusted computing platform initiative.) Domain Keys Identified Mail (DKIM) is the major technology promoted in support of secure messaging, in chapter thirteen. Chapter fourteen, about secure identity, has an analysis of a variety of technologies. (The recommendations about technologies are supported even less than before, and the work now starts to sound rather doctrinaire.) It may seem rather odd to talk about secure names as opposed to identities, but Hallam-Baker is dealing with identifiers such as email addresses and domain names in chapter fifteen. Chapter sixteen looks at various considerations in regard to securing networks, mostly in terms of authentication. Random thoughts on operating system, hardware, or application security make up chapter seventeen. The author stresses, in chapter eighteen, that the law, used in conjunction with security technologies, can help in reducing overall threat levels. Chapter nineteen finishes off the text with a proposed outline of action that recaps the major points. Hallam-Baker uses a dry wit well, and to good effect in the book. The humour supports and reinforces the points being made. So does his extensive and generally reliable knowledge of computer technology and history. In certain areas the author is either less knowledgeable or careless in his wording, and, unfortunately, the effe
