I understand that the algorithms are what is essential to a properly functioning SC, but my question was more one of validation that the SC you are holding actually implements those algorithms properly. I've found SC vendors generally rather tight on providing full implementation details to the public, not to mention the issue of a class break if the shared key or private key are found if there's no way to update them.
Who said I was talking about soldiers? You do understand there's a lot more people in Iraq (and in lots of other places around the world) employed by the US Government than just front line troops, right?
Same goes for your VA benefits line. This policy covers *any* sensitive data, and I'm sure you'll agree that government laptops can and do have data of varying degrees of sensitivity that make it sensible to adopt a broad policy to cover all of them rather than enact another level of bureaucracy just to decide what policy applies to which PC?
So, nice kneejerk assuming I was playing the "for the troops" card, but you're wrong.
Some corporations are still running Windows 98. Many are on Windows 2000. Very rarely will a corporation migrate to a one month old operating system - they'll trial it in very select areas to shake out the bugs and tech support issues they are likely to face and then deploy 6-30 months later (depending on the date of their upgrade cycle).
Vista *will* roll out to businesses, but don't expect it to overtake XP any faster than XP overtook 2000, or 2000 overtook 98, etc.
The primary attack vector I can see is not booting from the disk and replacing the boot loader with something more "friendly" to attack (or sniffing of a proper passphrase), but without a TPM there's not much you can do to avoid that.
My concern with smart cards is the transparency of implementation. How sure can you really be of tamper resistance, or even of its resistance to a MITM attack?
I tend to agree though - smart card+PIN can lead to a better security system than a straight password. I'm glad no one mentioned biometrics - that's a singularly bad idea for a number of reasons.
If you're in a HUMM-V in Iraq, do you really want to be setting up a satellite connection just to use your laptop? I stand by my case that disconnected operation is essential.
I'd imagine running a mail server on a laptop would be useful for sending mail when disconnected from the network. At least, that's why I use sendmail on my laptops. Remember, these people are concerned with quick fixes that don't reduce remote functionality - not reducing the laptops to a minimal install and minimal functionality.
Databases can be placed anywhere the account that the database server is running as has the rights to put them. I sure don't have access to/var/mysql on my laptop (as a regular user) but I can access databases just fine. It's that whole client/server model thing that lets this happen. Yes, you could encrypt them on a case by case basis, but full disk encryption guarantees that you catch everything.
If you have a rootkit and are admin you can just sniff whatever the user is doing. Smartcard doesn't help you there. Seriously, once you're root then ANYTHING that goes through the laptop is compromised.
I think the TPM solution is useful and shows the real use behind the TPM: corporate machines where it's clear the end user doesn't own the machine but is just an unprivileged user. I know the bitlocker stuff on Vista uses the TPM for full disk encryption, so seeing a *nix implementation of the same can't be hard to find.
Just curious - does the system support multiple "user" entries? What is the boot sequence and does it require specialized hardware, or just has an unencrypted bootloader? What defenses does it have against someone putting a trojan bootloader in that grabs the key?
It's actually more secure to have an essentially random password that people secure on a laminated card in their wallet (appropriately obfuscated of course) than have passwords that people can easily remember. When you think about it, people are actually very good at securing their wallet independently of their laptops.
In this era of high bandwidth connections and VPN, why can't the data be accessed from home or via laptop without it existing physically on the hard drive?
Because not every government employee has access to high bandwidth connections, especially if they are stationed outside the US. Disconnected operation is essential.
Why full disk encryption and not just the home directory?? Maybe things are so mixed up on Windows that you need full disk, but on OS X, Linux, and other Unixes it should be sufficient to encrypt only the home directory of users.
Yes, Windows is rather mixed up but *nix puts sensitive data outside the home directories all the time. Take the following examples:
/var/log has dozens of email addresses, all sorts of handy info on networking connections etc.
Databases can exist pretty much anywhere, though usually in/var. These are where the real data leaks happen anyway, not in ~.
Consider a laptop that you just have access to for long enough to install a rootkit (using a boot cd)?
There's lots of good arguments for full disk encryption. The downsides are:
i) Key management and authentication. A USB dongle that you can lose along with the laptop, or a password policy that encourages people to tape post-its to their machines defeats any advantage. ii) Retrofitting. Full disk encryption really requires BIOS level support in the true sense of the word.
Exactly. A whole bunch of law is about intent, and if you intentionally are pointing people to illegal mp3s then you deserve to have the law come down hard on you. If the ISP also knew what was going on then I have no sympathy for them. If, however, the ISP had no knowledge and was acting on good faith of their customer's lawfulness then I doubt there would have been a case against them.
The usual Slashdot hysteria just has this flat out wrong. This does not mean all linking is illegal, just deliberately linking or deliberately assisting in the publishing of links to illegal material is wrong. It's the same reason you can't publish a newspaper advert for "cheap CD copies, fresh from China" in the local newspaper and I doubt anyone would be defending either the advertiser or the newspaper when they got in legal trouble for such an advertisment.
Well - one thing will. Not allowing the attacker to get root in the first place.
This is what I'm trying to reinforce. There is no point in considering defenses against an attacker who has root. At that point, you are being grossly negligent if you do anything but forensic analysis and removing the machine from a public network until such time as you can do something to prevent future incursions of the type that went through. Inventing clever tricks to stop root from hacking your machine is in the realms of the tooth fairy, and DRM/copy prevention companies. It's simply a level of obfuscation in place after your real security failed, not a true measure of security.
Now, on the plus side of a read-only root disk, it does tend to permit a faster restore to a "known" configuration in the event of a successful root attack. You still have to pull the machine from the network and plug the hole, but the downtime may be a lot faster assuming you have physical access to the box.
I'm not assuming anything is on a read-write disk. If the attacker is able to load arbitrary code into the kernel then it doesn't matter where/etc/fstab is - they can just rewrite the kernel at runtime to mount a disk without worrying about/etc/fstab.
Yes - your machine will be "clean" after a reboot, but because you've made it read only it will be vulnerable to whatever attack gave them root in the first place.
Any system - read/write or read only root drive can be reset to a known configuration with little effort (it's usually called "restoring from a backup"), but the point of the rootkit is to give you no reason to do this. Your system looks like it's running just fine and your security theater of making the root drive read-only is giving you a warm fuzzy feeling about how safe you are, but in reality an attacker owns your box and you have no idea.
The answer is to spend less time thinking about what if an attacker gets root and more time preventing them. Once they have root it's pretty simple: nothing is trustworthy on the box any more because you have hard empirical evidence that it's weak to an attack.
Vista benchmarks the flash and the HDD. If, as you suggest, the HDD speed exceeds the flash memory speed then it simply doesn't lose the flash and you lose nothing. On the other hand, if the memory stick (or *any* other removeable storage device) benchmarks faster then it uses it.
So, in the end you can't lose and you can gain. I don't see your problem?
*Note that your numbers are incorrect too. USB flash disks are 20-30 MB/s (bytes, not bits). HDD speeds currently are around 4-5MB/s, which is almost an order of magnitude slower.
But having things like/usr/bin on a read-only drive seems like an effective way to protect against many, many different root-kits, worms, etc. Ineffective and simply feel-good security.
If someone has root on your box (which is needed to install a rootkit) then they can just copy the read-only system to the writeable disk and mount it r/w. Now, given that they *already* know how to get root on the box then rebooting will clear whatever changes they made, but also put your system back into the configuration that they've demonstrated they can get root on anyway. You're dead in the water.
Lesson: If someone has root privileges (or equivalent, ie they can load arbitrary code into the kernel) on a machine then they own that machine. Doesn't matter what kernel hackery, obfuscated kernel modules, clever mountpoint strategies or anything else you come up with, they can undo it.
It's "bunk" in the sense it doesn't supplement main memory. What it does is move part of the disk cache from main memory to the flash drive, and uses heuristics to precache some of the most used apps from the drive to flash. No volatile data is stored on the flash drive, and while there will obviously be a performance decrease if you yank the stick out while it has to load stuff from disk instead of hitting main memory, the tradeoff is probably worth it.
It's not like the heuristics change that often that your most used apps are switching around all the time, and overall it's not a bad idea for using flash as a disk cache given the improved read speeds. Technically, this is a pretty interesting feature. It's just a shame the marketing gets the message so damn confused.
Where did you see the Battle.Net code? Did you work for Blizzard or are you talking about bnetd?
Should have been more specific - the first I observed this behavior was in looking at the way games connected to Battle.Net and subsequently to each other. I haven't actually looked at the code itself in either Battle.Net or bnetd.
Most (if not all) game engines do it, and have been doing it since the late '90s. If I recall correctly, the first I saw it was the original Battle.Net code but that doesn't mean B.Net didn't get it from someone before that.
Those numbers are significantly higher than the core US market. Comcast over here is pretty much crowing about their ability to hit 10Mb if the phase of the moon is right and you have nice neighbors who couldn't tell a computer from a cow.
In any case, 10Mb, 20Mb, 24Mb - it's all the same really and still two orders of magnitude below local storage (which was my point). The whole "data cloud" concept relies on the idea that network storage will be as cheap and accessible as local storage.
The problem with the whole "Data Cloud" thing is that the network bandwidth just isn't there yet. I get impatient enough waiting for my files from my LOCAL hard drive (which has a peak transfer of around a gigabit per second) and yet the best broadband access you can get at the moment is lucky to exceed ten megabits peak transfer (and forget sustained). It's the same issue with network backups - you just can't transfer the terabyte of information I have on my home machine to anywhere on the internet fast enough for it to be called anything even approaching useful. I'll just keep the RAID setup for now, thanks.
Sorry, but I've been hearing about the wonders of storing all my data on some network drive for a long time now, but the storage requirements of "all my data" have been growing faster than the network bandwidth has. Until that trend is reversed, local storage is here to stay.
No security should be dependent on the technology implementing it not being distributed. A truly secure system should assume that someone wanting to penetrate it can amass every piece of technology used and STILL not allow someone through. Making your security depend on the bad guys not getting equipment XYZ is just obfuscation, not security at all.
In the case of boarding passes it's simple - you check each one against the central database of valid passes for that flight. If you get two passes for the same seat then you know at least one is a fraud and you can deal with things from there.
Slashdot Mirror
I understand that the algorithms are what is essential to a properly functioning SC, but my question was more one of validation that the SC you are holding actually implements those algorithms properly. I've found SC vendors generally rather tight on providing full implementation details to the public, not to mention the issue of a class break if the shared key or private key are found if there's no way to update them.
Who said I was talking about soldiers? You do understand there's a lot more people in Iraq (and in lots of other places around the world) employed by the US Government than just front line troops, right?
Same goes for your VA benefits line. This policy covers *any* sensitive data, and I'm sure you'll agree that government laptops can and do have data of varying degrees of sensitivity that make it sensible to adopt a broad policy to cover all of them rather than enact another level of bureaucracy just to decide what policy applies to which PC?
So, nice kneejerk assuming I was playing the "for the troops" card, but you're wrong.
Some corporations are still running Windows 98. Many are on Windows 2000. Very rarely will a corporation migrate to a one month old operating system - they'll trial it in very select areas to shake out the bugs and tech support issues they are likely to face and then deploy 6-30 months later (depending on the date of their upgrade cycle).
Vista *will* roll out to businesses, but don't expect it to overtake XP any faster than XP overtook 2000, or 2000 overtook 98, etc.
And Notes won't run? Damn - I'm upgrading NOW.
Makes sense.
The primary attack vector I can see is not booting from the disk and replacing the boot loader with something more "friendly" to attack (or sniffing of a proper passphrase), but without a TPM there's not much you can do to avoid that.
My concern with smart cards is the transparency of implementation. How sure can you really be of tamper resistance, or even of its resistance to a MITM attack?
I tend to agree though - smart card+PIN can lead to a better security system than a straight password. I'm glad no one mentioned biometrics - that's a singularly bad idea for a number of reasons.
If you're in a HUMM-V in Iraq, do you really want to be setting up a satellite connection just to use your laptop? I stand by my case that disconnected operation is essential.
I'd imagine running a mail server on a laptop would be useful for sending mail when disconnected from the network. At least, that's why I use sendmail on my laptops. Remember, these people are concerned with quick fixes that don't reduce remote functionality - not reducing the laptops to a minimal install and minimal functionality.
/var/mysql on my laptop (as a regular user) but I can access databases just fine. It's that whole client/server model thing that lets this happen. Yes, you could encrypt them on a case by case basis, but full disk encryption guarantees that you catch everything.
Databases can be placed anywhere the account that the database server is running as has the rights to put them. I sure don't have access to
If you have a rootkit and are admin you can just sniff whatever the user is doing. Smartcard doesn't help you there. Seriously, once you're root then ANYTHING that goes through the laptop is compromised.
I think the TPM solution is useful and shows the real use behind the TPM: corporate machines where it's clear the end user doesn't own the machine but is just an unprivileged user. I know the bitlocker stuff on Vista uses the TPM for full disk encryption, so seeing a *nix implementation of the same can't be hard to find.
Just curious - does the system support multiple "user" entries? What is the boot sequence and does it require specialized hardware, or just has an unencrypted bootloader? What defenses does it have against someone putting a trojan bootloader in that grabs the key?
It's actually more secure to have an essentially random password that people secure on a laminated card in their wallet (appropriately obfuscated of course) than have passwords that people can easily remember. When you think about it, people are actually very good at securing their wallet independently of their laptops.
Because not every government employee has access to high bandwidth connections, especially if they are stationed outside the US. Disconnected operation is essential.
Yes, Windows is rather mixed up but *nix puts sensitive data outside the home directories all the time. Take the following examples:
There's lots of good arguments for full disk encryption. The downsides are:
i) Key management and authentication. A USB dongle that you can lose along with the laptop, or a password policy that encourages people to tape post-its to their machines defeats any advantage.
ii) Retrofitting. Full disk encryption really requires BIOS level support in the true sense of the word.
Exactly. A whole bunch of law is about intent, and if you intentionally are pointing people to illegal mp3s then you deserve to have the law come down hard on you. If the ISP also knew what was going on then I have no sympathy for them. If, however, the ISP had no knowledge and was acting on good faith of their customer's lawfulness then I doubt there would have been a case against them.
The usual Slashdot hysteria just has this flat out wrong. This does not mean all linking is illegal, just deliberately linking or deliberately assisting in the publishing of links to illegal material is wrong. It's the same reason you can't publish a newspaper advert for "cheap CD copies, fresh from China" in the local newspaper and I doubt anyone would be defending either the advertiser or the newspaper when they got in legal trouble for such an advertisment.
Well - one thing will. Not allowing the attacker to get root in the first place.
This is what I'm trying to reinforce. There is no point in considering defenses against an attacker who has root. At that point, you are being grossly negligent if you do anything but forensic analysis and removing the machine from a public network until such time as you can do something to prevent future incursions of the type that went through. Inventing clever tricks to stop root from hacking your machine is in the realms of the tooth fairy, and DRM/copy prevention companies. It's simply a level of obfuscation in place after your real security failed, not a true measure of security.
Now, on the plus side of a read-only root disk, it does tend to permit a faster restore to a "known" configuration in the event of a successful root attack. You still have to pull the machine from the network and plug the hole, but the downtime may be a lot faster assuming you have physical access to the box.
I'm not assuming anything is on a read-write disk. If the attacker is able to load arbitrary code into the kernel then it doesn't matter where /etc/fstab is - they can just rewrite the kernel at runtime to mount a disk without worrying about /etc/fstab.
Yes - your machine will be "clean" after a reboot, but because you've made it read only it will be vulnerable to whatever attack gave them root in the first place.
Any system - read/write or read only root drive can be reset to a known configuration with little effort (it's usually called "restoring from a backup"), but the point of the rootkit is to give you no reason to do this. Your system looks like it's running just fine and your security theater of making the root drive read-only is giving you a warm fuzzy feeling about how safe you are, but in reality an attacker owns your box and you have no idea.
The answer is to spend less time thinking about what if an attacker gets root and more time preventing them. Once they have root it's pretty simple: nothing is trustworthy on the box any more because you have hard empirical evidence that it's weak to an attack.
Vista benchmarks the flash and the HDD. If, as you suggest, the HDD speed exceeds the flash memory speed then it simply doesn't lose the flash and you lose nothing. On the other hand, if the memory stick (or *any* other removeable storage device) benchmarks faster then it uses it.
So, in the end you can't lose and you can gain. I don't see your problem?
*Note that your numbers are incorrect too. USB flash disks are 20-30 MB/s (bytes, not bits). HDD speeds currently are around 4-5MB/s, which is almost an order of magnitude slower.
It's "bunk" in the sense it doesn't supplement main memory. What it does is move part of the disk cache from main memory to the flash drive, and uses heuristics to precache some of the most used apps from the drive to flash. No volatile data is stored on the flash drive, and while there will obviously be a performance decrease if you yank the stick out while it has to load stuff from disk instead of hitting main memory, the tradeoff is probably worth it.
It's not like the heuristics change that often that your most used apps are switching around all the time, and overall it's not a bad idea for using flash as a disk cache given the improved read speeds. Technically, this is a pretty interesting feature. It's just a shame the marketing gets the message so damn confused.
Should have been more specific - the first I observed this behavior was in looking at the way games connected to Battle.Net and subsequently to each other. I haven't actually looked at the code itself in either Battle.Net or bnetd.
Most (if not all) game engines do it, and have been doing it since the late '90s. If I recall correctly, the first I saw it was the original Battle.Net code but that doesn't mean B.Net didn't get it from someone before that.
Those numbers are significantly higher than the core US market. Comcast over here is pretty much crowing about their ability to hit 10Mb if the phase of the moon is right and you have nice neighbors who couldn't tell a computer from a cow.
In any case, 10Mb, 20Mb, 24Mb - it's all the same really and still two orders of magnitude below local storage (which was my point). The whole "data cloud" concept relies on the idea that network storage will be as cheap and accessible as local storage.
The problem with the whole "Data Cloud" thing is that the network bandwidth just isn't there yet. I get impatient enough waiting for my files from my LOCAL hard drive (which has a peak transfer of around a gigabit per second) and yet the best broadband access you can get at the moment is lucky to exceed ten megabits peak transfer (and forget sustained). It's the same issue with network backups - you just can't transfer the terabyte of information I have on my home machine to anywhere on the internet fast enough for it to be called anything even approaching useful. I'll just keep the RAID setup for now, thanks.
Sorry, but I've been hearing about the wonders of storing all my data on some network drive for a long time now, but the storage requirements of "all my data" have been growing faster than the network bandwidth has. Until that trend is reversed, local storage is here to stay.
Err... no.
Every nation that has done this rounds to the nearest nickel, not the next highest.
...and have mail to unknown users forward to their own mailbox, do they have to register every possible alphanumeric combination?
How about on IRC when the server decides arbitrarily to change your nick:
SexOffender is now known as SexOffender_
SexOffender_ tells #SupportGroup: @()$*@$. Now I have to register the new nick!
No security should be dependent on the technology implementing it not being distributed. A truly secure system should assume that someone wanting to penetrate it can amass every piece of technology used and STILL not allow someone through. Making your security depend on the bad guys not getting equipment XYZ is just obfuscation, not security at all.
In the case of boarding passes it's simple - you check each one against the central database of valid passes for that flight. If you get two passes for the same seat then you know at least one is a fraud and you can deal with things from there.
My bad. Misread your post. Please feel free to consider mine an affirmation of your idea.