> On 6/25/07, Ian Murdock <[EMAIL PROTECTED]> wrote: >> Another huge win for laptops would be disk encryption (for the lost >> or stolen laptop scenario). > > Agreed.
During my days doing government and military work we had systems that we called tempest systems. They were shielded and with crypto hardware. Doing such a thing with software may be possible but non-trivial I would think. The real issue on the table should be to get a UNIX derivitive distro going and not to re-invent the wheel. Just my two cents. More money below. >> One question is the user interface.. Presumably >> the system bits don't need to be encrypted, just the user bits, > > I think there may be couple problems with that approach because the he > separation between system bits and user bits can be pretty difficult > to sort out. One may envision files that are crypto and those that are clear. This is common in secure systems. However the entire filesystem hierarchy and code that supports it is typically quite customized to that purpose. > - Is /etc system bits or user bits? I'll go with the assumption that > it is user bits. If the shadow file is compromised then a dictionary > attack could be used to get passwords that are likely used on other > seemingly non-compromised systems. > > - Does anything important ever make it to /var/tmp? > > - Where are VPN configuration files stored? Last time I paid > attention (previous employer many years ago), there was a shared > secret that was used during the initial exchanges to secure the > channel before authentication took place. My understanding was that > if this key was compromised it could allow MITM attacks. Probably MITM attacks based on the probability that a given key could decipher the contents of the conversation throughout the entire stream. A cipher block approach that rotates keys and chooses new keys based on privately owned algorithms, that is to say at the valid ends of the conversation, would defeat the MITM who can only decipher some initial blocks before the next key rotate. However now we have moved from file based crypto to conversation or telecom based crypto. A whole other world again. Also non-trivial. > My assumption is that the data is only encrypted on disk. When it is > in the ARC it would be unencrypted. As such, system data would need > to be decrypted during boot. This would be a CPU hit, but I would > guess that boot time is dominated by disk speeds (use compression > too!) and using up extra CPU during boot would not be much of a > burden. Commonly used files (e.g. libc, that man page you keep > reading) would be in the ARC uncompressed and unencrypted, giving > traditional access speeds and no computational overhead. > >> so perhaps the encryption key is just the user's >> password, and the key is supplied to ZFS when the user logs in? > > Interesting approach for an individual home directory. It should be > relatively easy to add this into the PAM stack as similar tricks have > been done in the Linux world for creating/mounting home directories at > login. It sounds interesting and of value long term but a little outside of the scope of Indiana I would think. - Dennis Clarke _______________________________________________ indiana-discuss mailing list [email protected] http://opensolaris.org/mailman/listinfo/indiana-discuss
