Re: encrypted file system issues (was Re: PGP master keys)
[A bit off topic but I thought I'd let it through anyway. Those uninterested in OS design should skip the rest of this message. --Perry] On 5/1/06, [EMAIL PROTECTED] (Perry E. Metzger) wrote: Disk encryption systems like CGD work on the block level, and do not propagate CBC operations across blocks, so if the atomic disk block write assumption is correct (and almost all modern file systems operate on that assumption), you have no more real risk of corruption than you would in any other application. I haven't seen the failure specs on modern disk systems, but the KeyKOS developers ran into an interesting (and documented) failure mode on IBM disks about 20 years ago. Those IBM systems connected disks to a controller which was connected to a channel which was a specialized processor with DMA access to the main storage of the system. Note that these systems were designed in the days when memory was expensive, so there was an absolute minimum of buffering in the channel, controller, and disk. There are many possible failure modes, including power failure on the individual components, hardware failure/microprogram failure in the components, etc. The failure we experienced was a microcode hang in the channel (probably caused by a transient hardware failure), which also stopped the CPU. The failure occurred while the controller and disk was writing a block, and the channel ceased providing data. The specification for the controller was if the channel failed to provide data, it filled the block with the last byte received from the channel. If the channel and CPU had been running, the overrun would have been reported back to the OS with an interrupt. As it was, all we had was a partially klobbered disk block. Since KeyKOS was supposed to be a high reliability OS, we needed to code for this situation. Because of the design of the disk I/O system, there were only two disk blocks (copies of each other) where this kind of failure could cause a problem. We defined the format of these blocks so the last two bytes were 0xFF00. By checking for this pattern, we could determine if the block has been partially klobbered. We then had to ensure that we checked for correct write on one of the blocks before starting to write the other. Does anyone have any idea how modern disks and computers handle similar situations? Cheers - Bill --- Bill Frantz| gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP master keys
On 29 Apr 2006 02:00:18 -, StealthMonger [EMAIL PROTECTED] wrote: Interesting epilog: theregister has apparently now edited out all mention of master keys. They probably had their misunderstanding pointed out to them by countless people by now. But... did anyone else note the phrasing of the qualification Redmond ostensibly used? ``BitLocker has landed Redmond in some hot water over its insistence that there are no back doors for law enforcement.'' On first reading, one might assume they meant no back doors except for the overt corporate ADK, but that is not in fact what they said. Does anyone have any experience with disk or filesystem encryption, especially with regard to unclean shutdowns and power failures? Normal file systems are designed to fail in ways that are easy to clean up with fsck, but when you start to throw encryption into the mix, it seems like you can easily end up with something unrecoverable. Even without encryption I've seen apparent bugs in ext2fs on SMP machines that lead to sectors of nulls placed in files that were being written around the time the system crashed. Personally, I was playing with disk encryption on my system, shut down the system and something was holding file descriptors open... the system tried to kill everything three times, and then gave up and rebooted. As a consequence, I had my first unrecoverable data loss since I started keeping track (probably 1992 or so), since I had not backed up the data (the file system was too large for my backup device). Lesson learned! Now I do a nightly rsync to a partition that is only briefly mounted. Not as good as backup tapes, but it'll do for now. Are there any good solutions to the problem where a key isn't used frequently enough to stay in human memory, yet needs to be present in certain rare circumstances? Even with PGP keys... I've forgotten some of mine. Print it out and put it in a safety deposit box? I wonder if the typical corporate escrow key is exercised enough to avoid needing to write it down. IMHO interaction with human factors and imperfect hardware/software are understudied relative to their importance in actually having a functional robust real-world system. How complex can passwords be before users start to write them down? How many times does it take to memorize a passphrase? How frequently must one use it in order to retain it? -- Curiousity killed the cat, but for a while I was a suspect -- Steven Wright Security Guru for Hire http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
encrypted file system issues (was Re: PGP master keys)
Travis H. [EMAIL PROTECTED] writes: Does anyone have any experience with disk or filesystem encryption, especially with regard to unclean shutdowns and power failures? Normal file systems are designed to fail in ways that are easy to clean up with fsck, but when you start to throw encryption into the mix, it seems like you can easily end up with something unrecoverable. Not if you design it correctly. Disk encryption systems like CGD work on the block level, and do not propagate CBC operations across blocks, so if the atomic disk block write assumption is correct (and almost all modern file systems operate on that assumption), you have no more real risk of corruption than you would in any other application. The only real risk points come in if you're doing a re-key of the entire disk or some similar operation in which care must be taken with the design or you could leave yourself in an unknown state. Even without encryption I've seen apparent bugs in ext2fs on SMP machines that lead to sectors of nulls placed in files that were being written around the time the system crashed. Bugs happen in everything. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Disk Encryption (was: Re: PGP master keys)
I use the following approach to encrypting my disks. I use an encrypted loopback device. The version of losetup I use permits me to store the disk key in a PGP encrypted file and decrypt it (with gpg) when needed. I made many backups of the both my personal keyring and the file with the encrypted loop key. So the only secret I have to remember is the passphrase on my normal PGP key, which I am not liekly to forget. Of course there is a trade-off here. If my PGP key is compromised, my disk encryption is at risk (if the encrypted disk key file is compromised as well). -Jeff P.S. If you run a reasonably modern Linux system, and have more then one system, you can use drbd to implement software mirroring between the two systems. Clever use of openvpn and encrypted loopback devices can do this securely as well. -- = Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: PGP master keys
| issues did start showing up in the mid-90s in the corporate world ... | there were a large number of former gov. employees starting to show up | in different corporate security-related positions (apparently after | being turfed from the gov). their interests appeared to possibly reflect | what they may have been doing prior to leaving the gov. | | one of the issues is that corporate/commercial world has had much more | orientation towards prevention of wrong doing. govs. have tended to be | much more preoccupied with evidence and prosecution of wrong doing. the | influx of former gov. employees into the corporate world in the 2nd half | of the 90s, tended to shift some of the attention from activities | related to prevention to activities related to evidence and prosecution | (including evesdropping). What I've heard described as the bull in the china shop theory of security: You can always buy new china, but the bull is dead meat. (I'm pretty sure I heard this from Paul Karger, who probably picked it up during his time at the Air Force.) | for lots of drift ... one of the features of the work on x9.59 from the | mid-90s | http://www.garlic.com/~lynn/x959.html#x959 | http://www.garlic.com/~lynn/subpubkey.html#x959 | | was its recognition that insiders had always been a major factor in the | majority of financial fraud and security breaches. furthermore that with | various financial functions overloaded for both authentication and | normal day-to-day operations ... that there was no way to practical way | of eliminating all such security breaches with that type of information. | ... part of this is my repeated comment on security proportional to risk | http://www.garlic.com/~lynn/2001h.html#61 The dodge of creating phantom troops and then collecting their pay checks has been around since Roman times. No one has ever found a way of detecting it cost-effectively. However, it's also been known forever that it's just about impossible to avoid detection indefinitely: The officer who created the troops gets transferred, or retires, and he has no way to maintain the fiction. Or the troops themselves are transferred. other events intervene. So armies focus on making sure they *eventually* find and severely and publicly punish anyone who tries this, no matter how long it takes. A large enough fraction of the population is deterred to keep the problem under control. A similar issue occurs in a civilian context, sometimes with fake employees, other times with fake bills. Often, these get found because they rely on the person committing the fraud being there every time a check arrives: It's the check sitting around with no one speaking for it that raises the alarm. The long-standing policy has been to *require* people in a position to handle those checks to take their vacation. (Of course, with direct deposit of salaries, the form of the fraud, and what one needs to do to detect it, have changed in detail - but probably not by much.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP master keys
[EMAIL PROTECTED] wrote: A similar issue occurs in a civilian context, sometimes with fake employees, other times with fake bills. Often, these get found because they rely on the person committing the fraud being there every time a check arrives: It's the check sitting around with no one speaking for it that raises the alarm. The long-standing policy has been to *require* people in a position to handle those checks to take their vacation. (Of course, with direct deposit of salaries, the form of the fraud, and what one needs to do to detect it, have changed in detail - but probably not by much.) multi-party operations were supposedly countermeasure to single person insider threads. the fraud response was collusion. so by at least the early 80s you started seeing work on collusion countermeasures. 25 years later, things have regressed to a pre-occupation with intrusion threats and intrusion countermeasures; even tho insiders have continued to be the major source of fraud through the whole period. insiders may even leverage the pre-occupation with intrusion to obfuscate the source of the exploit. somewhat related issue with regard to sarbanes-oxley and auditing assumptions about independent information sources looking for inconsistencies. http://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley http://www.garlic.com/~lynn/2006i.html#1 Sarbanes-Oxley and a couple recent articles about current fraud pre-occupation SSL Trojans: The next Great Bank Heist http://www.infoworld.com/reports/18SRsslmalware.html Ripped Off: Identity Theft - A View from the Financial Services Industry http://www.mondaq.com/article.asp?article_id=39334mostpopular=1 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted file system issues (was Re: PGP master keys)
On 5/1/06, Perry E. Metzger [EMAIL PROTECTED] wrote: Not if you design it correctly. Disk encryption systems like CGD work on the block level, and do not propagate CBC operations across blocks, So is it vulnerable to any of the attacks here? http://clemens.endorphin.org/LinuxHDEncSettings I used to run NetBSD 1.6 IIRC, and for some reason cgd was in previous and later releases but not that one. I found that puzzling. -- Curiousity killed the cat, but for a while I was a suspect -- Steven Wright Security Guru for Hire http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP master keys
Anne Lynn Wheeler wrote: issues did start showing up in the mid-90s in the corporate world ... there were a large number of former gov. employees starting to show up in different corporate security-related positions (apparently after being turfed from the gov). their interests appeared to possibly reflect what they may have been doing prior to leaving the gov. one of the issues is that corporate/commercial world has had much more orientation towards prevention of wrong doing. govs. have tended to be much more preoccupied with evidence and prosecution of wrong doing. the influx of former gov. employees into the corporate world in the 2nd half of the 90s, tended to shift some of the attention from activities related to prevention to activities related to evidence and prosecution (including evesdropping). for lots of drift ... one of the features of the work on x9.59 from the mid-90s http://www.garlic.com/~lynn/x959.html#x959 http://www.garlic.com/~lynn/subpubkey.html#x959 was its recognition that insiders had always been a major factor in the majority of financial fraud and security breaches. furthermore that with various financial functions overloaded for both authentication and normal day-to-day operations ... that there was no way to practical way of eliminating all such security breaches with that type of information. ... part of this is my repeated comment on security proportional to risk http://www.garlic.com/~lynn/2001h.html#61 the x9.59 approach was to eliminate the function overload so that the same information that was needed for normal day-to-day operation didn't also carry with it any authentication feature/attribute. the result was that data breaches could still occur, but no longer enabled the financial fraud that it once did ... and therefor it didn't really represent a serious security breach ... aka the countermeasure to financial fraud associated with the data breaches was to recognize that it was impossible to totally eliminate them, since the information was required extensively in day-to-day business processes, so to prevent the wrong doing, the authentication feature/attribute was removed from the associated information. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP master keys
Steven M. Bellovin wrote: Ah -- corporate key escrow. An overt back door for Little Brother, rather than a covert one for Big Brother the key escrow meetings attempted to differentiate between keys used for authentication and keys used for securing corporate data (I only went to a couple of the meetings). the case of key escrow as part of securing corporate data was similar to business processes for backing up corporate data, disaster recovery, and no single point of failure. in fact, escrow of authentication keys was equally a violation of business standards as not having escrow of encryption keys. there was cross-over from backup infrastructure and the transition from all corporate data residing in hardened datacenters to individual desktops ... where the they were finding critical corporate data being managed and maintained w/o adequate backup and recovery capabilities. the point of key escrow as part of infrastructure securing corporate data ... was that the data belonged to the corporation ... and loss of keys could be equivalent to losing the data ... and as such, was as negligent as not backing up critical corporate data and not having a disaster/recovery plan. there was some backup related study that claimed half of the corporations that had a disk failure (where the disk was not being backed up) containing critical corporate data ... filed for bankruptcy withing 30 days of the failure. i assumed that critical was stuff like account-billable files ... loosing a month worth of customer account billing information could create a real dent on the corporation's cash flow. one incident involved a corporation that lost something like $50m in monthly billings. it wasn't suppose to be a back door to anything ... anymore than having copies of all corporate files on corporate backup tapes (however, the corporate backup tapes wouldn't be worth a lot if all the data has been secured with encryption ... and the encryption keys are lost). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP master keys
note from the corporate side ... is was specifically the escrow of encryption keys for data at rest ... as part of prudent corporate asset protection; it was not escrow of authentication keys nor escrow of encryption keys used for communication. the internal network was larger than the arpanet/internet from just about the beginning until possibly around summer of 85. at the time of the great change-over to internetworking protocol on 1/1/83, the number of arpanet/internet nodes was approx. 250 (a number that the internal network had passed in the mid-70s, the internal network passed 1000 nodes a little later in 83). http://www.garlic.com/~lynn/subnetwork.html#internalnet corporate inter-site links had to be encrypted ... which at the time met link encryptors .. there was claims that the internal network had over half of all the link encryptors in the world. there wasn't any corporate escrow issues with link encryptor keys. there were various problems with gov. agencies ... significant problems especially in europe getting gov/ptt authorization for corporate link encryptors (on corporate links, between corporate sites, purely carrying corporate data) especially when the links crossed country boundaries. issues did start showing up in the mid-90s in the corporate world ... there were a large number of former gov. employees starting to show up in different corporate security-related positions (apparently after being turfed from the gov). their interests appeared to possibly reflect what they may have been doing prior to leaving the gov. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP master keys
and real-time reference from today ... on backup tapes ... at off-site location that weren't encrypted (and should have been): Data storage firm apologizes for loss of railroad data tapes Information on as many as 17,000 workers at risk http://www.boston.com/business/globe/articles/2006/04/28/data_storage_firm_apologizes_for_loss_of_railroad_data_tapes/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP master keys
Steven M. Bellovin [EMAIL PROTECTED] writes: In an article on disk encryption (http://www.theregister.co.uk/2006/04/26/pgp_infosec/), the following paragraph appears: BitLocker has landed Redmond in some hot water over its insistence that there are no back doors for law enforcement. As its encryption code is open source, PGP says it can guarantee no back doors, but that cyber sleuths can use its master keys if neccessary. What is a master key in this context? Interesting epilog: theregister has apparently now edited out all mention of master keys. In a version downloaded via the Agora web-to-mail gateway at Sat, 29 Apr 2006 03:42:05 +0900 (JST), the second sentence reads PGP says its open source encryption code also guarantees no back doors. (full stop) -- StealthMonger - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP master keys
Quoting Steven M. Bellovin [EMAIL PROTECTED]: In an article on disk encryption (http://www.theregister.co.uk/2006/04/26/pgp_infosec/), the following paragraph appears: BitLocker has landed Redmond in some hot water over its insistence that there are no back doors for law enforcement. As its encryption code is open source, PGP says it can guarantee no back doors, but that cyber sleuths can use its master keys if neccessary. What is a master key in this context? ADK, the Additional Decryption Key. An enterprise with a Managed PGP Desktop installed base can set up an ADK and all messages get encrypted to the ADK in addition to the recipient's key. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP master keys
On Wed, Apr 26, 2006 at 09:53:27PM -0400, Steven M. Bellovin wrote: In an article on disk encryption (http://www.theregister.co.uk/2006/04/26/pgp_infosec/), the following paragraph appears: BitLocker has landed Redmond in some hot water over its insistence that there are no back doors for law enforcement. As its encryption code is open source, PGP says it can guarantee no back doors, but that cyber sleuths can use its master keys if neccessary. What is a master key in this context? It sounds rather like a misunderstanding/mangling of PGP's Additional Decryption Key feature. David - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP master keys
On Wed, 26 Apr 2006 22:24:22 -0400, Derek Atkins [EMAIL PROTECTED] wrote: Quoting Steven M. Bellovin [EMAIL PROTECTED]: In an article on disk encryption (http://www.theregister.co.uk/2006/04/26/pgp_infosec/), the following paragraph appears: BitLocker has landed Redmond in some hot water over its insistence that there are no back doors for law enforcement. As its encryption code is open source, PGP says it can guarantee no back doors, but that cyber sleuths can use its master keys if neccessary. What is a master key in this context? ADK, the Additional Decryption Key. An enterprise with a Managed PGP Desktop installed base can set up an ADK and all messages get encrypted to the ADK in addition to the recipient's key. Ah -- corporate key escrow. An overt back door for Little Brother, rather than a covert one for Big Brother --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
PGP master keys
In an article on disk encryption (http://www.theregister.co.uk/2006/04/26/pgp_infosec/), the following paragraph appears: BitLocker has landed Redmond in some hot water over its insistence that there are no back doors for law enforcement. As its encryption code is open source, PGP says it can guarantee no back doors, but that cyber sleuths can use its master keys if neccessary. What is a master key in this context? --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
