Firewire threat to FDE
Hello, As if the latest research (which showed that RAM contents can be recovered after power-down) was not enough, it seems as Firewire ports can form yet an easier attack vector into FDE-locked laptops. Windows hacked in seconds via Firewire http://www.techworld.com/security/news/index.cfm?RSSNewsID=11615 The attack takes advantage of the fact that Firewire can directly read and write to a system's memory, adding extra speed to data transfer. IIUC, the tool mentioned only bypasses the Win32 unlock screen, but given the free access to RAM, exploit code that digs out FDE keys is a matter of very little extra work. This is nothing new. The concept was presented a couple of years ago, but I haven't seen most FDE enthusiasts disable their Firewire ports yet. Unsurprisingly: Microsoft downplayed the problem, noting that the Firewire attack is just one of many that could be carried out if an attacker already has physical access to the system. The claims [...] are not software vulnerabilities, but reflect a hardware design industry issue that affects multiple operating systems, Bill Sisk, Microsoft's security response communications manager, told Techworld. It is not *their* fault, but being a company that pretends to take users' security seriously, and being at a position that allows them to block this attack vector elegantly, I would have gone that extra half-mile rather than come up with excuses why not to fix it. All they need to do is make sure (through a user-controlled but default-on feature) that when the workstation is locked, new Firewire or PCMCIA devices cannot be introduced. That hard? Hagai. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Open source FDE for Win32
Hello Dave, On 13/2/2008 21:26, Dave Korn wrote: Or are you suggesting that it could encrypt each block OTF when it's first accessed, or run the encryption in the background while the system was still live, instead of converting the whole drive in one big bite? Encrypting blocks only when they are used can be risky in terms of false sense of security. There is basically no way for you to tell what is left out there. Encrypting the drive while the system is live is what TC currently does. Encryption runs in the background while you can do other things (though much slower). Hagai. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Open source FDE for Win32
Hello, On 11/2/2008 06:13, Ali, Saqib wrote: I installed TrueCrypt on my laptop and ran some benchmark tests/ Benchmark Results: http://www.full-disk-encryption.net/wiki/index.php/TrueCrypt#Benchmarks Pros: 1) Easy to use product. Simple clean interface. Very user-friendly! 2) Free and Open Source 3) Multiple Encryption and Hashing algorithm available. Cons: 1) Buffered Read and Buffered Transfer Rate was almost halved after TrueCrypt FDE was enabled :-(. 2) Access Time for large file (250+MB) increased by 11%. 3) The initial encryption of the 120 GB HDD took 2 hours. Actually, there is one major (but temporary) limitation to TC5: It does not process too well partitions that are not the system partition, but which share the same physical drive as the system partition, if you elect to encrypt the entire drive. That is, if you decide to encrypt a whole physical drive that stores both C: (system) and D: (another partition), you are going to face a situation in which your D: partition is logically gone (until you re-decrypt the whole thing back). Next version will fix it, the team promises. Hagai. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Open source FDE for Win32
List, Finally, an open source FDE (Full Disk Encryption) for Win32. It is the first one I am aware of: www.truecrypt.org TC is not a new player, but starting February 5th (version 5) it also provides FDE. Didn't get to try it yet. Hagai. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another Snake Oil Candidate
Hi, On 13/09/07 15:14, Ian G wrote: Hagai Bar-El wrote: Hi, On 12/09/07 08:56, Aram Perez wrote: The IronKey appears to provide decent security while it is NOT plugged into a PC. But as soon as you plug it in and you have to enter a password to unlock it, the security level quickly drops. This would be the case even if they supported Mac OS or *nix. As I stated in my response to Jerry Leichter, in my opinion, their marketing department is selling snake oil. I think there is a difference between a product that is susceptible to an attack and the pure distilled 100% natural snake oil, as we usually define it. So, is snake oil: * a crap product? * a fine product with weaknesses? * a marketing campaign that goes OTT? * a term used to slander the opposing security model? * an adjective that applies to any of the above? Just like any term, it can have many interpretations. However, the most useful definition is the one that you can find at http://en.wikipedia.org/wiki/Snake_oil_(cryptography) and which quite accurately reflects what the people who first brought this term into use used it for. Hagai. -- Hagai Bar-El - Information Security Analyst T/F: 972-8-9354152 Web: www.hbarel.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another Snake Oil Candidate
Hi, On 12/09/07 08:56, Aram Perez wrote: The IronKey appears to provide decent security while it is NOT plugged into a PC. But as soon as you plug it in and you have to enter a password to unlock it, the security level quickly drops. This would be the case even if they supported Mac OS or *nix. As I stated in my response to Jerry Leichter, in my opinion, their marketing department is selling snake oil. I think there is a difference between a product that is susceptible to an attack and the pure distilled 100% natural snake oil, as we usually define it. Indeed, the encrypted USB token is susceptible to sniffing of the password on the PC where it is entered. But in my opinion this is not the type of flaw that snake oils the product, because: 1. It's a limitation that also exists in the state of the art products of its type. That is, nobody could ever do better (I think). 2. It therefore does not reflect complete lack of understanding on the developer's side... So perhaps it's not pure snake oil but just a product with an attack vector; most products have at least one. Actually, this product is (almost) the first one that I saw which actually bothers to deal with the brute-force attack vector, which does exist in many other similar products. So it's not perfect, and I would certainly not bet my life on it, probably not even my life's data, but it's reasonable. Hagai. -- Hagai Bar-El - Information Security Analyst T/F: 972-8-9354152 Web: www.hbarel.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Enterprise Right Management vs. Traditional Encryption Tools
Hello, On 08/05/07 20:16, Ali, Saqib wrote: I was recently asked why not just deploy a Enterprise Right Management solution instead of using various encryption tools to prevent data leaks. Any thoughts? The encryption tools function according to simple, well understood, and more-or-less enforceable security models. Their assumptions are well understood and, most importantly, match the environments they run on. They solve a simple problem, and solve it effectively. Rights management solutions have complex security models, and run in environments that do not always satisfy the assumptions. They aim at providing complex functionality, but they often (always?) fail to deliver due to their over-complexity and unrealistic assumptions. If your security needs can be met by the simple functional model of the encryption tools, then you will prefer to enjoy the assurance and the reasonable robustness they provide, which is the most desirable feature after all. Hagai. -- Hagai Bar-El - Information Security Analyst T/F: 972-8-9354152 Web: www.hbarel.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: phone encryption technology becoming popular in Italy
Hello, On 02/05/07 20:12, Dave Korn wrote: Interesting, but of course they're still a good way from 100% secure. It's really great that they issue the source, but unless they also issue the toolchain, and the source to the toolchain, so that anyone who wants can recompile and reflash their phone, it's less than secure. I know these devices. You are right. The source code you get cannot be used for full assurance, because you don't get everything required to build an image and replace the existent one with it. The source you get allows you to check and be convinced that the code has no software bugs that were not intended by the vendor. It does not aim to assure you against malicious attempts by the vendor to introduce back-doors into the product. So, you are secure, just not against everything... It's still more than you get with completely closed-source devices, let alone with ones that implement proprietary crypto... And, of course, the source code is probably published also because the marketing guys (probably) said that people skilled in the art will appreciate this feature when evaluating this product against others. Hagai. -- Hagai Bar-El - Information Security Analyst T/F: 972-8-9354152 Web: www.hbarel.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More info in my AES128-CBC question
Hello Nico, On 25/04/07 02:18, Nicolas Williams wrote: If there isn't a good reason for rejecting what I suggest then one might worry that changing the integrity key on every message (but not the confidentiality key?) is something that a non-expert might do and that there may be other problems with this protocol. Much experience has been gained with other protocols in these areas; do leverage it. Is there anything wrong with changing the integrity key every message as means for preventing cut-and-paste attacks between messages or against taking messages out of their order? It may not be the most efficient way; adding a message counter to the HMAC does make more sense, but is there a problem with the way Aram uses now? (I don't see any.) But be careful. Simply chaining the IV from message to message will create problems (see SSH). What problem does this (chaining IV from message to message) introduce in our case? The intention would be a new IV with each message begin sent. As long as it doesn't repeat. Also, if it's not random then make that IV the first block of plaintext (with a fixed IV) -- that is, use a confounder, and make sure it doesn't repeat. It seems as Aram uses a different IV for each message encrypted with CBC. I am not sure I see a requirement for randomness here. As far as I can tell, this IV can be a simple index number or something as predictable, as long as it does not repeat within the same key scope. A legitimate response w.r.t. confounders might be but that wastes a cipher block's worth of bits on the wire, which it certainly does, and if you're really hard pressed for bandwidth and use mostly small messages then you'd mind the confounder. But I see no reason not to use a random or pseudo-random IV -- a device that can do crypto can and should have a decent PRNG (and a true, if low-bandwidth RNG to seed it). I don't understand the difference between a confounder and an IV in terms of bits on the wire. After all, in both cases the confounder or IV need to be passed to the other side, unless they are implicitly known. Hagai. -- Hagai Bar-El - Information Security Analyst T/F: 972-8-9354152 Web: www.hbarel.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More info in my AES128-CBC question
Hello David, On 22/04/07 00:04, David Wagner wrote: Hagai Bar-El writes: What Aram wrote is many of the attendees have very little security experience, not: there are no attendees with security experience. There are people at the relevant OMA group who know enough about security, but just like in the real world -- they are outnumbered by plain feature-set people, and thus have to come up with very clear arguments to get their way. So the people who don't know anything about security are reluctant to listen to those who do? That's not a good sign. It may be standard operating procedure in groups like this, but that doesn't make it right. It's still dysfunctional and dangerrous. If the committee doesn't have a commitment to security and is reluctant to listen to the experts, that's a risk factor. The group is not reluctant to listen, but it does expect to hear firm reasoning, so the security consideration weights properly among other, as important, considerations. Security gurus A' say A, Performance gurus B' say B, which may partially conflict with A, and UI gurus C' say C. If the product is broken then it's dead, but also if the product is slow and annoys people, and also if average people can't use it for UI reasons. It's easy to make a product that is never used, even if it's secure. When we look at things, we see them as secure/insecure, but the market and the economy sees a more complex picture where security is very important, but is one important factor along with other important factors that influence the design decision. As long as security comes for no cost -- sure, why not. However, when security comes at a cost that may make the product less useful, A' need to convince (A' U B' U C') that they should have their way. If you're sick and you go to a doctor, do you tell the doctor you'd better come up with some very clear arguments if you want me to follow your advice? Do you tell your doctor you'd better build a strong case before I will listen to you? I would hope not. That would be silly. Doctors are medical professionals with a great deal of training and expertise in the subject. They can speak with authority when it comes to your health. So why do people with no training in security think that they can freely ignore the advice of security professionals without any negative consequences? As long as what the Doctor says costs you very little (in terms of risk and/or money), you follow his advice blindly because challenging it will cost you more. When the doctor tells you that you need a heart surgery -- you do challenge it: you try to get a second opinion, you ask him to explain the case in ways you can understand and be able to gain more information on the subject. At least I hope you do. People don't ignore security professionals. However, when high costs are involved, challengeable rationale is called for. As long as economy is not a single-factor B/W, this is how it should be. AND (3) If you don't care about replacement attacks on the (1 to i) blocks that will result only in a (possibly-undetected) corruption when decrypting the i+1 block (rather than two blocks, with a varying and non-attacker-changeable). [...] Wait a minute. This reference to replacement attacks has me concerned. Does the protocol use a message authentication code (MAC)? I hope so. If your protocol uses a MAC, and uses it properly, then replacement attacks are not an issue, and the only issue with using a fixed IV is related to confidentiality. If you don't use a MAC, you've got bigger problems, and even random IVs won't be enough. I generally agree. Some protocols try to be cheap on MAC, assuming that the strict structure of the protocol will cause a failure if something goes bad. For example, if a message has an intrinsic entropy of 2 bits (say, a return status code), and is sent as one block (you can't send less), then you don't really need a MAC, as long as the recipient knows not to crash disgracefully if it receives an invalid status code. I guess my point is meaningless for the case in question, as MACs are used... Hagai. -- Hagai Bar-El - Information Security Analyst T/F: 972-8-9354152 Web: www.hbarel.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More info in my AES128-CBC question
Hello all, On 20/04/07 08:32, Aram Perez wrote: The proposal for using AES128-CBC with a fixed IV of all zeros is for a protocol between two entities that will be exchanging messages. This is being done in a standards body (OMA) and many of the attendees have very little security experience. As I mentioned, the response to my question of why would we standardize this was that's how SD cards do it. I'll look at the references and hopefully convince enough people that it's a bad idea. Relating to the anger at the random bunch of people [who] design crypto protocols: What Aram wrote is many of the attendees have very little security experience, not: there are no attendees with security experience. There are people at the relevant OMA group who know enough about security, but just like in the real world -- they are outnumbered by plain feature-set people, and thus have to come up with very clear arguments to get their way. Aram figured fixed IV's is generally a bad idea, and probably so did others at OMA, but since the security people have to build a case and not just say well, it's generally not a good idea, a more descriptive explanation of possible attacks (a justification) was sought for. Now to the subject matter: I do not know the protocol in question, but in a nutshell: Generally, CBC with a fixed IV (be it zero or any other value) is to be avoided for the reason described in previous posts. In some circumstances this restriction may be relaxed, such as: (1) if the first unknown (to the attacker) block _always_ follows (not necessarily immediately) a session-specific block (a block that is not likely to repeat for the same key, such as a message-id). For example, if every encrypted structure starts with an id that never repeats among structures, and all security-wise meaningful blocks follow it, you are _probably_ safe. (2) if the key is never re-used among structures you encrypt. AND (3) If you don't care about replacement attacks on the (1 to i) blocks that will result only in a (possibly-undetected) corruption when decrypting the i+1 block (rather than two blocks, with a varying and non-attacker-changeable). For example: If Message #1 and Message #2 are encrypted with the same key, you can take blocks 1,2,3,..,i of Message #2 and paste them in Message #1, and only block i+1 will decrypt badly. If you had protected (attacker unchangeable) and varying IV's, block 1 would have decrypted badly too, for whatever it's worth. (Comment: block 1 can be any higher index, as long as there are no earlier blocks that differ between the messages.) As the others stressed: the implication of these conditions/limitations, as well as others which I may have not spotted, depend on the protocol... Hagai. P.S. Aram, as you know, I am signed on the OMA NDA, so you can send me the protocol. If other members here are signed on the OMA NDA, I guess it could be useful if you notified Aram in a private message, so you can get your copy and examine it too. -- Hagai Bar-El - Information Security Analyst T/F: 972-8-9354152 Web: www.hbarel.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Governance of anonymous financial services
Hello, On 29/03/07 21:30, Steve Schear wrote: Here is the situation. An on-line financial service, for example a DBC (Digital Bearer Certificate), operator wishes his meat space identity, physical whereabouts, the transaction servers and at least some of the location(s) of the service's asset backing to remain secret. The service provides frequent, maybe even real-time, data on its asset backing versus currency in circulation. The operator wishes to provide some assurance to his clients that the backing and the amount of currency in circulation are in close agreement. The mint's backing need not be in a single location nor in the sole possession of the operator. I realize this is a governance question but I suspect that crypto/data security may play a key role. Some questions: If independent auditors are used do they need to know the operator's identity? Putting the crypto capabilities aside for a moment, what is the purpose of auditing an anonymous legal entity? Auditing, as I see it, can be used to serve two systems: 1. An intrinsically-enforced reputation system 2. An extrinsically-enforced legal system When I take my hard earned money and deposit it with the local branch of ABC bank, I do it while relying on two things: 1. The bank is part of a national legal trademarking system that assures me that this branch having this nice red ABC logo, is the same ABC Bank that all my friends use, along with millions of others, and so far, they haven't been fooled and their money hasn't yet been stolen. This #1 is something I can get from a pseudonym based system that is accompanied by some auditing I trust, even if the bank is completely anonymous. In the optimal installation you try to achieve the auditor I trust will be able to tell me: This bank, that you do not know where it is, and so don't I, has the backing for the currency it has in circulation. I will also be able to tell it's the same bank my friends use. 2. The bank is part of a legal *enforcement* system, such that if the bank takes my hard earned money and refuses to give it back to me, the *human* manager of the bank will be put in *physical* handcuffs and taken to a physical prison, where he cannot physically exercise his freedoms, such as go to a pub, see his kids, etc. No web-site extortion, no reduction of virtual credibility points, not even bad publicity; jail. Real jail, with non-chosen roommates and bad meals. I want to know that the enforcement system that the bank is subject to is one that can lead to real jail before I trust a web-site with my real money. This is along the lines of the baseball bat that Ian mentioned. This is something I cannot get from a system in which there may be auditing, but there is no chain connecting the digital world (as intrinsically-enforced as it would be), and the physical world, that offers better enforcement means, better matching my money's worth. The enforcement that is offered by the legal system is tied to the physical world and thus requires identifiability and personal (flesh -- not username) accountability. You can have a system do without it; have only intrinsic enforcement without tying to the physical world, but I believe its enforcement will never be strong enough to win the trust of the masses when it comes to hard earned money. At the end of the day, say everything works perfectly by your model, and the intrinsic system can prove that there is a coin of gold for every $x in circulation. How does the user know that he will ever see the sums he put in circulation. He has a receipt, of course, but a receipt is just a bunch of bits. These bits may prove to a third party that justice is with the user, but what will link this justice back to money if the bank's owner doesn't feel like paying? I know this is not completely related to the questions you presented, but more to the rationale of the entire system. I am just trying to understand this better. Regards, Hagai. -- Hagai Bar-El - Information Security Analyst T/F: 972-8-9354152 Web: www.hbarel.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Practical Security Mailing List
Hello, I would like to notify you all of a new mailing list forum which I opened. It is called Practical Security and is aimed at discussing security measures in the context of real problems in real projects. It has a much narrower scope than the Cryptography mailing list and by no means intends to replace it or to compete with it. From the mailing list info page: This forum discusses applications of cryptographic protocols as well as other security techniques, such as (but not limited to) methods for authentication, data protection, reverse-engineering protection, denial-of-service protection, and digital rights management. The forum also discusses implementation pitfalls to avoid. This forum does not discuss theoretical and/or mathematical aspects of cryptography. Neither does the forum discuss particular vulnerabilities of commercial products, such as what one may find in BugTraq. Joining this mailing list is especially recommended to professionals who design security systems and to application designers who are also responsible for the security aspects of their products. I confess that at the moment of writing the list has just a few participants, but I project that it will grow much larger. To subscribe visit http://www.hbarel.com/practicalsecurity or send a blank message to [EMAIL PROTECTED] Regards, Hagai. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Standardization and renewability
Dear Colleagues, I am currently in the process of writing a short position paper about standardization of broadcast renewability schemes. Along with the usual challenges that need to be addressed when defining renewability methods (methods that allow a system to survive successful attacks, basically by changing itself throughout its lifecycle), I am trying to tackle what I consider to be the biggest problem of standardizing a renewability scheme, which is that evolving a standard is too slow and cumbersome of a process to be incorporated into another process that is all about prompt response. Simply put, if a broadcast mechanism is broken there is no time for the standardization committee to re-define it - too much content will be lost by the time the job is done. Up till now I could come up with three approaches to solve this problem: 1. Limit renewability to keying. 2. Generalize the scheme (like the SPDC concept, or MPEG IPMP), more or less by making the standard part general, with non-standard profiles. 3. Standardize sets of key management methods at once, so to have spares for immediate switching. If any one of you has any other approach towards solving this issue I will be glad if he posts it on the list. Also, if any one of you would like to get a copy of this paper when it's done, please let me know by e-mailing me directly. Regards, Hagai. --- Hagai Bar-El - Information Security Analyst T/F: 972-8-9354152 Web: www.hbarel.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Opinion on Israeli espionage plot
List, In the following link is an opinion about the espionage act discovered in Israel a week ago. In short: This case is probably one of dozens, but the only one that was discovered probably due to three non-typical mistakes that were done. http://www.hbarel.com/Blog/entry0004.html Hagai. --- Hagai Bar-El - Information Security Analyst T/F: 972-8-9354152 Web: www.hbarel.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
