I'd mod you up if I had points. I think you're absolutely right on tablets. Desktops and laptops will have a way to turn off secure boot for legacy reasons. A fair number of customers will want to run XP/Vista/7, and/or old add-on cards that aren't fully UEFI compatible.
But tablets are another story. There is little expectation that someone would install an old OS on a Windows 8 tablet, since Windows 8 is the first tablet-friendly Windows OS. Yes, there might be some Linux options, but I don't think that will influence the market as much on tablets as it might on desktops or laptops. Just as significantly, the hardware in the tablet is the only hardware you'll ever run on that device. You don't need support for legacy option ROMs to support old add-on cards.
It would be difficult to have a meaningful signature on the bootloader right now, given that its the first OS component that is loaded during boot. You need some sort f root of trust that is loaded before the OS, which basically means it needs to be in the BIOS. The bootloader would need to be signed using a private key corresponding to a public key that is loaded on the Windows 8 logo PCs. Since Microsoft probably hasn't even completely gotten that UEFI secure boot signing service up yet, I doubt that the bootloader is signed in a way that is compatible with UEFI secure boot.
Though you're right, Windows 7 already supports UEFI boot. For Windows 7 itself to support secure boot you would probably just need a fairly simple OS update.
But, the bigger problem for existing systems is option ROMs. I doubt Nvidia has released a UEFI device driver for their cards. Secure boot probably forces you down a UEFI-only boot path, meaning you can't execute legacy option ROMs. That might not be a problem for some, except that you probably want to initialize your video card at boot so you can see what's going on.
You make it sound like authentication using a digital credential on a TPM is worse than other options. It's almost certainly better than any other option with a comparable cost. Sure, some high-end crypto modules have better protections against invasive or side channel attacks, but you're not going to put several thousand dollar crypto modules in laptops. You're certainly much better off using an RSA key pair stored on a TPM compared to a key pair stored on disk. And even that would be considered very strong compared to the more common authentication mechanisms, like passwords, one-time password devices, and one-time passwords sent via SMS.
The kind of attack you're imagining would work on any cryptographic authentication scheme. To manufacture fake credentials that someone might actually trust you'd need to get a CA to sign the public key you create. You can't steal the signing key for the CA by just taking something off the TPM, because the CA signing key is not on the TPM.
And, to make things even harder for an attacker, you probably can't just get any CA to sign your credential. If you want access to NASA's network, you probably need to get a NASA CA to sign the public key. This is because the deployment model for TPMs is very different than that of something like SSL web sites. With typical SSL deployments you'd just need to get one out of a relatively large number of trusted CAs to sign your public key.
OK. So suppose you get an EK off a TPM. Then what? I agree you can do that- TPMs aren't designed to thwart advanced invasive hardware attacks. They probably wouldn't even do very well against some side channel attacks.
But, it's not an attack that scales well. You need to get physical access to one machine, potentially put forth a fair amount of resources attacking that one machine, and then you get one stolen identity out of it.
This is definitely not a simple case of supply and demand. Universities are expensive to run. It costs a certain amount of money to educate a student. Sure, you could drop that cost by paying professors less, having larger classes sizes, limiting courses, limiting research opportunities etc., but at some point the quality of education will drop. You can complain about school administrators making high-6 or 7 digit salaries, but I doubt you'd claim the CEO of a similarly sized corporation is overpaid. It costs money to attract people that are good at running large organizations. You can complain about professor "wasting university resources" doing research, but those professors are creating new inventions, and training undergraduate and graduate researchers that will go on to invent in the public or private sectors.
Remember, except in a few cases, universities and colleges do not have a profit motive. You shouldn't expect the same economic motives to apply.
But I agree, subsidized or guaranteed student loans, grants and scholarships have had an effect. Lots of people that otherwise couldn't have gone to college have now gone on to college. We have artificially increased the demand, and the market adapted by creating bigger and bigger schools. It definitely did not adapt by raising prices so a similar number of students went to college. We've creating a level of demand that can't remain without the subsidies. If the subsidies went away, fewer people would go to college, some schools would close, and others would have to get a lot smaller. Although, you'd probably see trade schools grow, but that has a much lower value today, otherwise more people would be going to them (since they're subsidized too).
If what you are saying is true- that colleges really are just wasting money and you'd get the same education out of a cheaper school- then more for-profit schools would form and rake in the money. It's not like students like spending $20-40k on tuition. It's that your degree from the Washington University, or even the University of Missouri, is going to be more valuable than a degree from the University of Phoenix, particularly for your first job.
And I really want to stress this point: I think you're significantly undervaluing research at universities. The US isn't going to have a vibrant economy by going back to low-skill jobs or manufacturing. About the only path to maintaining the economy we've grown accustomed to is to lead the new in the development of new technology. That's what research projects at universities attempt to do. Professors are trying to invent new things, and along the way undergraduates and graduates try to learn how to do that themselves. While there are certainly a number of "idea men" in the IT world that came up with an idea and marketed it, I think overall you'd find a large percentage of the people ultimately responsible for creating a new technology have a PhD (or maybe an MS). These might be a relatively small percentage of the overall undergraduate student population, but they go on to have a huge impact on our economy and our way of life.
Well, we already know a secure boot process is coming to upcoming systems, because Microsoft is requiring UEFI Secure Boot on Windows 8 logo systems. That was discussed previously on slashdot, and its actually a little bit closer to what people seem to be afraid will happen with TPMs. TPMs can really only measure the boot process (letting anything run, but being able to say later what ran at boot), but UEFI secure boot is intended to lock it down so only signed code runs at boot.
As a side note, I'd actually say recent experiences with consoles and smart phones show that it is feasible to very tightly lock down the boot process. The Xbox 360 has withstood software-only rooting very well. The PS3 has done OK, although they certainly screwed up with the attack on the private key. Cell phones designed to prevent rooting (e.g., a lot of Motorola phones with signed bootloaders) actually do pretty well against full roots.
But I find it interesting that you're saying that the availability of new computing platforms makes you less concerned. Besides virtualization (which I realize is your key example), I think new computing platforms will be locked down from the start, or at least lock-able down. Things like iPads, iPhones, and other tablets and phones are the key examples. I think we'll see at least some heavily locked down Windows 8 tablets, but time will tell. Most people don't like worrying about security, and locking down the device is one way to take some of that responsibility away from the user.
In any case, I really think people would be more supportive of things like TPMs and trusted computing if they really understood what they do. For instance, I know there's a lot of interest in bring-your-device-to-work, that is, using your personal cell phone, tablet or laptop for work. You can't do that today because of security concerns and (probably more significantly) compliance with regulations. Your company only knows certain key protective measures are in place on your work laptop because they are the ones that set it up, and its set up so you can't change it. The paradigm could be very different with trusted computing and TPMs. With that technology, your company could scan your machine for compliance with their regulations, and grant you access to network resources if your system is found compliant. Perhaps many members of the Slashdot community wouldn't like the idea of their employers scanning their machines, but I think a lot of people would happily deal with that if it meant they could use their iPhone or iPad at work.
I don't work in the DRM space, but I do work in the cryptography and computer security space, and I've had a number of dealings with Wave Systems. They may have been building their company around DRM technologies years ago, but that doesn't seem to be a strong area of interest for them currently.
Also, this isn't the only place the British government has been pushing trusted computing. The government official may have been speaking to the choir, but I suspect he meant everything he said (although I also suspect the article is pulling the IP theft comment out of context, but I obviously wasn't there).
Sure, but you have to start somewhere. The first code that runs on the main CPU will pretty much always have to be implicitly trusted. Actually, in theory you could get Intel to sign the CRTM code using a private key corresponding to a public key that is stored on Intel CPUs. But, I suspect you'd need a combination of hardware and software changes to get the CPU to start up in a mode that would only run signed code. And, you'd probably always have a little bit of code somewhere that needs to be implicitly trusted, although you could put it in true ROM.
You could also use tangential technologies, like Intel TXT, to reliably measure the state of a running system, and then just use the TPM to sign those measurements. It's hard to do that correctly, but it's a very powerful reporting mechanism.
I'd mod you up, but I've already posted on this article. unity100 clearly doesn't know how TPMs work. Actually, lots and lots of people commenting on this article don't understand TPMs. They think they do much, much more than they actually can. Basically, they can store hashes of things like the BIOS code or configuration data that are executed on boot, and they can perform digital signature operations (usually as either part of an authentication protocol or to sign hashes of BIOS code, etc.). The TPM can't enforce anything itself, because it never has control on the main CPU. The BIOS would have to do that. Things like UEFI Secure Boot are actually a lot closer to what people are afraid of than TPMs.
In any event, unity100's complaints are invalid. As you said, the digital credentials on TPMs are unique, so "cracking" a TPM will just get you the credential off that TPM. That's not very exciting. There are no system-wide shared secrets on TPMs, unless you decide to put one on it for your organization (which would be a bad idea). There is a sort of certificate authority which has a secret signing key, but even getting a hold of that doesn't necessarily lead to dire situations. An attacker with a forged identity using a stolen CA signing key would still have to get that forged credential into a company's authentication system, at least in typical TPM deployments. And, whoever can modify the digital credentials in the authentication system has a huge amount of power- but that's always the case.
One correction though- no one uses DAA. It's technically supported in the TPM specification, but I've had a really hard time figuring out which, if any, TPMs actually have DAA implemented on the chip. Seriously, to the best of my knowledge, no one is using DAA, and I don't think that's an exaggeration.
What? I don't know of a single product that Wave sells that is DRM-related, at least using the copyright protection definition of the term. Most of Wave's products are related to managing full disk encryption systems, like Bitlocker or self-encrypting drives.
First of all, HFA inhalers typically have about 100 doses, not 200. One dose is almost always two "puffs" from the inhaler.
I don't know where you're getting this idea that a single inhaler can last someone 1-3 years. "Well-controlled" asthma is considered to be someone that only needs to use their inhaler 3 times per week, not counting any additional doses used when exercising. If you exercise 3 times a week like you're supposed to, that means an inhaler could last you about 3 months.
Except, the medications designed to keep asthma under control are expensive. They make HFA albuterol inhalers look cheap. Depending on the medication and the dose, each of those medications can run $60-$120 per month. Some people, like me, need two. Often, people need to take other medications to combat their triggers (e.g., allergy medication to deal with allergy-induced asthma attacks, or GERD medications). Those aren't terribly expensive, but these things add up.
It would be great if everyone could afford to keep their asthma under control, but that's not the case. And it's low-income suffers that are most at-risk. Yes, in an ideal world people wouldn't use albuterol inhalers on a daily basis, but that's better than just trying to push yourself through the symptoms of an attack unmedicated.
First of all, HFA inhalers are significantly more expensive than CFC inhalers, because there are no generics available. HFA epinephrine inhalers would likely have the same problem.
In addition, no one claims epinephrine inhalers work as well as albuterol inhalers, but you can't get those over-the-counter.
You can probably implement something pretty close to this if you fully implement the UEFI specification. I think you can whitelist hashes of UEFI device drivers and boot loaders, in addition to verifying them using digital signatures. Though, I'm not sure anyone will implement that part of the UEFI specifications.
It's not comparable. As WorBlux said, DVD's encryption scheme was just weak. UEFI secure boot uses much, much stronger cryptography. BluRay uses cryptography of similar strength, but the problem with BluRay is that you had to give every bluray player (hardware and software) a copy of a secret key. There are lots of different players, and it only took one poorly protected key to leak out to destroy the security of that scheme. And to make matters worse, you were basically giving everyone devices that held those secret keys.
In the case of UEFI secure boot, you don't need to give everyone a secret key. You just need to give them a public key. It doesn't matter if someone can read that public key- you just can't let them [easily] change it.
I agree the on/off setting for secure boot should be locked down after boot, but the list of trusted certificates is explicitly intended to be modifiable after boot. It's basically implemented with UEFI authenticated variables (i.e., signed variables). The OS (or some application running on the OS), it supposed to be able to overwrite an authenticated variable by supplying a new, properly signed string. The UEFI BIOS will verify the signature on the newly supplied string prior to overwriting the variable.
Then I have great news for you! At least, for your first wish. If all you want is a TPM-based trusted boot, then you can do that today. A TPM-based trusted boot just stores hashes of the BIOS, option ROMs, boot loader, etc., executed during boot. You can later access those hashes, and report the hashes to another server (signed by the TPM, of course, so you can't fake them).
UEFI secure boot doesn't use a TPM. The UEFI BIOS will verify option ROMs and boot loaders prior to executing them. A TPM isn't very useful for doing that, and therefore isn't used. Of course, if there is a TPM, Microsoft will happily store hashes of its critical system files on the TPM during the boot process, and it can access those hashes (and hashes the BIOS, opROMs, etc.) later on.
Your second wish is possible, but don't hold your breath.
The rogue CA demonstration attack on MD5 was important. It showed the attack wasn't entirely theoretical. Some thought that even though you could find collisions in MD5 easily enough, you wouldn't be able to find meaningful collisions that could be used an attack. This demonstration showed you could do a real attack without needing a ridiculous amount of processing power.
However, as Mathinker said, the weaknesses in MD5 and SHA-1 really aren't problems at all for password hashing. Collision attacks don't help you invert hash functions- preimage attacks do. There aren't any serious preimage attacks on MD5 or SHA-1. There's a theoretical preimage attack against MD5, but from a practical perspective its probably much slower than brute-force search.
Also, salted hashes only help you so much. Yes, they help block attacks using rainbow tables, but was was described in this article was just a regular old brute force search without the use of rainbow tables. So, for an attack like this, salted hashes don't make it any more difficult for an attacker to get one password, but it would make it more difficult for an attacker to invert a bunch of hashed passwords from a stolen password database.
Strictly speaking, NIST still allows the use of SHA-1 for password hashing. NIST says you shouldn't use SHA-1 for anything that requires collision resistance. Password hashing doesn't require collision resistance, it only requires preimage resistance. In fact, there's relatively little benefit to using SHA-256 or SHA-512 for password hashing, since they're not that much slower than SHA-1 and its not much harder to generate and store a SHA-2 rainbow table than a SHA-1 rainbow table.
The page you referenced is from 2006, and NIST has backed off on their warnings about SHA-1 a little bit. The collision attack on SHA-1 probably isn't as bad as it looked in 2006. The attack hasn't improved- some of the alleged improved attacks turned out to have errors in them. No one has ever found a collision using SHA-1. Some people aren't even sure the claimed collision attack even works, though the general agreement is that even if the specific attack outlined in Wang's paper doesn't work, there probably is a similar one that does work.
In the mid 2000's the cryptographic community just saw both of the widely used hash functions attacked- SHA-1 and MD5. There were a lot of people concerned that the attacks would soon be catastrophic. That certainly didn't come true with SHA-1, and its only partially true with MD5 (which still has decent preimage resistance).
Still, telling people to move to SHA-2 is good general-purpose advice. It can be tricky to determine when you need collision resistance and when preimage resistance will do.
You don't just hash a password when you you store a new password. You also have to hash the password every time a user logs in. Now I agree you could certainly increase the iteration count on passwords, but one full second of computation on a busy server isn't going to fly. Companies have pushed back over far less. It has taken a long time to get where we are today when it comes to using TLS for login pages, and that's far less than one second of computation. Far fewer companies continue to use TLS once you get off the login page, even though the symmetric encryption operations that take place after the initial key establishment are even less computationally intensive.
I was just the example of twice the work to show how much easier it is to make brute-forcing a key infeasible versus brute-forcing a password. Yes, I'm sure you can do more than twice the work. But you're not going to get away with doing 3 billion clock cycles. I think you'd have a hard time getting people to deploy enough iterations to block brute-forcing attacks. And even if you do, it would be short-term fix. Bumping up the key length of an encryption algorithm can extend security a long time. From a practical perspective, AES-256 should work indefinitely, as long as someone doesn't break the algorithm itself. There's probably not enough energy in the universe to brute-force a 256-bit key, and quantum computers don't help that much. Bumping up the iteration count by a factor of 50 or so (any more and I think you'd have a hard time getting people to deploy it) basically just gets you the same thing as another character in the password. That's not enough to block these attacks. And by the time you'd actually get that deployed password crackers would be even more powerful. And since you can't get companies to change crypto algorithms and protocols constantly, you'd basically be stuck with that for 5-10 years.
You're not going to close hole with higher iteration counts alone.
It's not that simple. Cryptography is an asymmetric game: you always have to assume the attacker has orders of magnitude more computing resources than the target. Cryptography works because we can (usually) find problems that get exponentially harder and harder to crack. For instance, let's say you just want to encrypt something. A block cipher with a 64-bit key is just on the edge of being brute-forcible today. But, as a general rule, you could use a block cipher with a 128-bit key and it should only be half as fast as the 64-bit cipher (note I said this is a general rule, there are number of factors that influence speed). A 128-bit block cipher is 2^64 times more difficult to crack than a 64-bit block cipher. So, the target can make something 2^64 times more difficult to crack by just doing twice the work.
Your proposed solution just grows linearly, not exponentially. If you iterate SHA-1 10,000 times instead of just 5,000 you're also doing twice the work, but this time you've only made your password twice as difficult to crack. If you can suddenly start doing twice the work you did before, you have to assume the attackers can as well.
Yes, iterating hash functions buys us more time, but this is a game that targets can't win. Plus, you're ignoring all of the problems associated with moving to higher iteration counts. Probably first and foremost is interoperability. There's a massive application base out there that just uses MD5 or SHA1 with little to no iteration. It's not easy for software like Windows to change. I think it wasn't until Vista that Microsoft stopped storing a LAN Manager hash of users' passwords, which made then trivial to break. That's been known to be bad for a long, long time. Plus, in most web-based applications its not the client that does the hash operation, its the server. While your new Core i5 processor could probably easily handle bumping up the iteration count by an order of magnitude or so, Google's Gmail servers probably can't.
Longer, more complicated passwords would be more effective than increasing iteration counts, but people are bad at generating and remembering long passwords. So, the only long term solution seems to be moving to stronger forms of authentication, like smart cards or using devices like smart phones as one-time password devices.
School policies are usually pretty benign. Most of the time there's nothing wrong with the language of a policy per se, but they are often quite vague. And 99% of the time it's fine that a given policy is vague, since reasonable people are perfectly capable of looking at a situation and coming up with a reasonable response (and yes, school administrators are usually reasonable people).
But, when people get put on the defensive, they'll often try to justify their actions. Vaguely written policies are very easy to point to as justification. So, while I basically agree that school policies are generally reasonable, I'm far less inclined to say a student necessarily did something wrong just because he violated a policy. It's certainly possible that we're not getting the whole story here, but it seems like what we do know from the article points to authorities attempting to justify their actions. The article said the student was "very cooperative" with authorities, which to me suggests he didn't say anything like "It's a bomb!", or that he talked back to the vice principal or authorities.
And, for what it's worth, I don't think the response to the device was entirely unreasonable. I just think the vice principal and authorities should feel a little more embarrassed given what had actually happened.
That's why I think people shouldn't criticize the vice principal too much for calling authorities to look into this. He wouldn't have done so unless he thought there was a reasonable chance that this thing was a bomb. Maybe he should have known better, but he didn't, and I'm not going to fault him for erring on the side of caution. But, I am troubled that the school and authorities seem to be blaming the kid and parents for this, like they should have known better than to bring a geeky home project to a *technology magnet school*. I would consider this a non-story if the school, vice principal, and authorities showed a little embarrassment over this situation, but they really seem to think this family did something horribly wrong.
I agree it's sort of hard to know one way or the other, but I think the author of the article is implying the student and parents need counseling so this sort of thing doesn't happen again. The article's statement about counseling was stated right after it discussed the fire officials searching the home for explosives. And, it was in the same paragraph that said the student wasn't going to be prosecuted, but violated school policies. The article does talk about the student and parents being upset, but that's a little later in the article.
Maybe the author of the article is misleading us, but (somewhat uncharacteristically) Slashdot's summary seems to be pretty accurate.
I think I might know why we're disagreeing. MPEG can mean lots and lots of things. As we already know, its often used to describe a codec and a container. But really, there are multiple containers that sometimes go by MPEG for short, since they all come out of the MPEG standard.
There's the MPEG version 1 container, which Quicktime does support out-of-the-box. Then there's the MPEG-Program Stream container, which I thought was the same thing until today (it might just be a that these are different versions of a similar type, basically MPEG-1-PS and MPEG-2-PS, but I'm not sure). However, Quicktime cannot read MPEG-PS files. There's also the MPEG-Transport Stream, although that usually doesn't get confused with the other two as much, since it usually doesn't have a.mpg extension.
Its my understanding that Perian doesn't add support for any of these containers. Quicktime includes support for MPEG-1-PS. Apple's Quicktime MPEG Component adds support for both the MPEG2 decoder and the MPEG-2-PS container. But, as far as I know, there's no way to get support for MPEG-Transport Streams. Apple explicitly says they don't support it.
In addition, Final Cut Pro includes the Apple Quicktime MPEG Component. So, if you're able to play back mpg files, its probably because either they're not MPEG-PS files, or it's because you already have the MPEG component installed.
I came to this conclusion by trying to play back different.mpg files, and using MediaInfo to figure out what the format/container was used for each file. Then I did some searching online to make sure what I found was consistent with the MPEG page on Wikipedia, Apple's MPEG Component page, and Perian's page.
Slashdot Mirror
I'd mod you up if I had points. I think you're absolutely right on tablets. Desktops and laptops will have a way to turn off secure boot for legacy reasons. A fair number of customers will want to run XP/Vista/7, and/or old add-on cards that aren't fully UEFI compatible.
But tablets are another story. There is little expectation that someone would install an old OS on a Windows 8 tablet, since Windows 8 is the first tablet-friendly Windows OS. Yes, there might be some Linux options, but I don't think that will influence the market as much on tablets as it might on desktops or laptops. Just as significantly, the hardware in the tablet is the only hardware you'll ever run on that device. You don't need support for legacy option ROMs to support old add-on cards.
It would be difficult to have a meaningful signature on the bootloader right now, given that its the first OS component that is loaded during boot. You need some sort f root of trust that is loaded before the OS, which basically means it needs to be in the BIOS. The bootloader would need to be signed using a private key corresponding to a public key that is loaded on the Windows 8 logo PCs. Since Microsoft probably hasn't even completely gotten that UEFI secure boot signing service up yet, I doubt that the bootloader is signed in a way that is compatible with UEFI secure boot.
Though you're right, Windows 7 already supports UEFI boot. For Windows 7 itself to support secure boot you would probably just need a fairly simple OS update.
But, the bigger problem for existing systems is option ROMs. I doubt Nvidia has released a UEFI device driver for their cards. Secure boot probably forces you down a UEFI-only boot path, meaning you can't execute legacy option ROMs. That might not be a problem for some, except that you probably want to initialize your video card at boot so you can see what's going on.
You make it sound like authentication using a digital credential on a TPM is worse than other options. It's almost certainly better than any other option with a comparable cost. Sure, some high-end crypto modules have better protections against invasive or side channel attacks, but you're not going to put several thousand dollar crypto modules in laptops. You're certainly much better off using an RSA key pair stored on a TPM compared to a key pair stored on disk. And even that would be considered very strong compared to the more common authentication mechanisms, like passwords, one-time password devices, and one-time passwords sent via SMS.
The kind of attack you're imagining would work on any cryptographic authentication scheme. To manufacture fake credentials that someone might actually trust you'd need to get a CA to sign the public key you create. You can't steal the signing key for the CA by just taking something off the TPM, because the CA signing key is not on the TPM.
And, to make things even harder for an attacker, you probably can't just get any CA to sign your credential. If you want access to NASA's network, you probably need to get a NASA CA to sign the public key. This is because the deployment model for TPMs is very different than that of something like SSL web sites. With typical SSL deployments you'd just need to get one out of a relatively large number of trusted CAs to sign your public key.
OK. So suppose you get an EK off a TPM. Then what? I agree you can do that- TPMs aren't designed to thwart advanced invasive hardware attacks. They probably wouldn't even do very well against some side channel attacks.
But, it's not an attack that scales well. You need to get physical access to one machine, potentially put forth a fair amount of resources attacking that one machine, and then you get one stolen identity out of it.
If only systems today did that well.
This is definitely not a simple case of supply and demand. Universities are expensive to run. It costs a certain amount of money to educate a student. Sure, you could drop that cost by paying professors less, having larger classes sizes, limiting courses, limiting research opportunities etc., but at some point the quality of education will drop. You can complain about school administrators making high-6 or 7 digit salaries, but I doubt you'd claim the CEO of a similarly sized corporation is overpaid. It costs money to attract people that are good at running large organizations. You can complain about professor "wasting university resources" doing research, but those professors are creating new inventions, and training undergraduate and graduate researchers that will go on to invent in the public or private sectors.
Remember, except in a few cases, universities and colleges do not have a profit motive. You shouldn't expect the same economic motives to apply.
But I agree, subsidized or guaranteed student loans, grants and scholarships have had an effect. Lots of people that otherwise couldn't have gone to college have now gone on to college. We have artificially increased the demand, and the market adapted by creating bigger and bigger schools. It definitely did not adapt by raising prices so a similar number of students went to college. We've creating a level of demand that can't remain without the subsidies. If the subsidies went away, fewer people would go to college, some schools would close, and others would have to get a lot smaller. Although, you'd probably see trade schools grow, but that has a much lower value today, otherwise more people would be going to them (since they're subsidized too).
If what you are saying is true- that colleges really are just wasting money and you'd get the same education out of a cheaper school- then more for-profit schools would form and rake in the money. It's not like students like spending $20-40k on tuition. It's that your degree from the Washington University, or even the University of Missouri, is going to be more valuable than a degree from the University of Phoenix, particularly for your first job.
And I really want to stress this point: I think you're significantly undervaluing research at universities. The US isn't going to have a vibrant economy by going back to low-skill jobs or manufacturing. About the only path to maintaining the economy we've grown accustomed to is to lead the new in the development of new technology. That's what research projects at universities attempt to do. Professors are trying to invent new things, and along the way undergraduates and graduates try to learn how to do that themselves. While there are certainly a number of "idea men" in the IT world that came up with an idea and marketed it, I think overall you'd find a large percentage of the people ultimately responsible for creating a new technology have a PhD (or maybe an MS). These might be a relatively small percentage of the overall undergraduate student population, but they go on to have a huge impact on our economy and our way of life.
Well, we already know a secure boot process is coming to upcoming systems, because Microsoft is requiring UEFI Secure Boot on Windows 8 logo systems. That was discussed previously on slashdot, and its actually a little bit closer to what people seem to be afraid will happen with TPMs. TPMs can really only measure the boot process (letting anything run, but being able to say later what ran at boot), but UEFI secure boot is intended to lock it down so only signed code runs at boot.
As a side note, I'd actually say recent experiences with consoles and smart phones show that it is feasible to very tightly lock down the boot process. The Xbox 360 has withstood software-only rooting very well. The PS3 has done OK, although they certainly screwed up with the attack on the private key. Cell phones designed to prevent rooting (e.g., a lot of Motorola phones with signed bootloaders) actually do pretty well against full roots.
But I find it interesting that you're saying that the availability of new computing platforms makes you less concerned. Besides virtualization (which I realize is your key example), I think new computing platforms will be locked down from the start, or at least lock-able down. Things like iPads, iPhones, and other tablets and phones are the key examples. I think we'll see at least some heavily locked down Windows 8 tablets, but time will tell. Most people don't like worrying about security, and locking down the device is one way to take some of that responsibility away from the user.
In any case, I really think people would be more supportive of things like TPMs and trusted computing if they really understood what they do. For instance, I know there's a lot of interest in bring-your-device-to-work, that is, using your personal cell phone, tablet or laptop for work. You can't do that today because of security concerns and (probably more significantly) compliance with regulations. Your company only knows certain key protective measures are in place on your work laptop because they are the ones that set it up, and its set up so you can't change it. The paradigm could be very different with trusted computing and TPMs. With that technology, your company could scan your machine for compliance with their regulations, and grant you access to network resources if your system is found compliant. Perhaps many members of the Slashdot community wouldn't like the idea of their employers scanning their machines, but I think a lot of people would happily deal with that if it meant they could use their iPhone or iPad at work.
I don't work in the DRM space, but I do work in the cryptography and computer security space, and I've had a number of dealings with Wave Systems. They may have been building their company around DRM technologies years ago, but that doesn't seem to be a strong area of interest for them currently.
Also, this isn't the only place the British government has been pushing trusted computing. The government official may have been speaking to the choir, but I suspect he meant everything he said (although I also suspect the article is pulling the IP theft comment out of context, but I obviously wasn't there).
Sure, but you have to start somewhere. The first code that runs on the main CPU will pretty much always have to be implicitly trusted. Actually, in theory you could get Intel to sign the CRTM code using a private key corresponding to a public key that is stored on Intel CPUs. But, I suspect you'd need a combination of hardware and software changes to get the CPU to start up in a mode that would only run signed code. And, you'd probably always have a little bit of code somewhere that needs to be implicitly trusted, although you could put it in true ROM.
You could also use tangential technologies, like Intel TXT, to reliably measure the state of a running system, and then just use the TPM to sign those measurements. It's hard to do that correctly, but it's a very powerful reporting mechanism.
I'd mod you up, but I've already posted on this article. unity100 clearly doesn't know how TPMs work. Actually, lots and lots of people commenting on this article don't understand TPMs. They think they do much, much more than they actually can. Basically, they can store hashes of things like the BIOS code or configuration data that are executed on boot, and they can perform digital signature operations (usually as either part of an authentication protocol or to sign hashes of BIOS code, etc.). The TPM can't enforce anything itself, because it never has control on the main CPU. The BIOS would have to do that. Things like UEFI Secure Boot are actually a lot closer to what people are afraid of than TPMs.
In any event, unity100's complaints are invalid. As you said, the digital credentials on TPMs are unique, so "cracking" a TPM will just get you the credential off that TPM. That's not very exciting. There are no system-wide shared secrets on TPMs, unless you decide to put one on it for your organization (which would be a bad idea). There is a sort of certificate authority which has a secret signing key, but even getting a hold of that doesn't necessarily lead to dire situations. An attacker with a forged identity using a stolen CA signing key would still have to get that forged credential into a company's authentication system, at least in typical TPM deployments. And, whoever can modify the digital credentials in the authentication system has a huge amount of power- but that's always the case.
One correction though- no one uses DAA. It's technically supported in the TPM specification, but I've had a really hard time figuring out which, if any, TPMs actually have DAA implemented on the chip. Seriously, to the best of my knowledge, no one is using DAA, and I don't think that's an exaggeration.
What? I don't know of a single product that Wave sells that is DRM-related, at least using the copyright protection definition of the term. Most of Wave's products are related to managing full disk encryption systems, like Bitlocker or self-encrypting drives.
First of all, HFA inhalers typically have about 100 doses, not 200. One dose is almost always two "puffs" from the inhaler.
I don't know where you're getting this idea that a single inhaler can last someone 1-3 years. "Well-controlled" asthma is considered to be someone that only needs to use their inhaler 3 times per week, not counting any additional doses used when exercising. If you exercise 3 times a week like you're supposed to, that means an inhaler could last you about 3 months.
Except, the medications designed to keep asthma under control are expensive. They make HFA albuterol inhalers look cheap. Depending on the medication and the dose, each of those medications can run $60-$120 per month. Some people, like me, need two. Often, people need to take other medications to combat their triggers (e.g., allergy medication to deal with allergy-induced asthma attacks, or GERD medications). Those aren't terribly expensive, but these things add up.
It would be great if everyone could afford to keep their asthma under control, but that's not the case. And it's low-income suffers that are most at-risk. Yes, in an ideal world people wouldn't use albuterol inhalers on a daily basis, but that's better than just trying to push yourself through the symptoms of an attack unmedicated.
First of all, HFA inhalers are significantly more expensive than CFC inhalers, because there are no generics available. HFA epinephrine inhalers would likely have the same problem.
In addition, no one claims epinephrine inhalers work as well as albuterol inhalers, but you can't get those over-the-counter.
You're absolutely right that you can wipe out protections if you can muck with the BIOS. But computer vendors are working on solving that problem too. Did you see this: http://en.community.dell.com/dell-blogs/direct2dell/b/direct2dell/archive/2011/07/22/securing-government-it-from-the-ground-up.aspx ?
You can probably implement something pretty close to this if you fully implement the UEFI specification. I think you can whitelist hashes of UEFI device drivers and boot loaders, in addition to verifying them using digital signatures. Though, I'm not sure anyone will implement that part of the UEFI specifications.
It's not comparable. As WorBlux said, DVD's encryption scheme was just weak. UEFI secure boot uses much, much stronger cryptography. BluRay uses cryptography of similar strength, but the problem with BluRay is that you had to give every bluray player (hardware and software) a copy of a secret key. There are lots of different players, and it only took one poorly protected key to leak out to destroy the security of that scheme. And to make matters worse, you were basically giving everyone devices that held those secret keys.
In the case of UEFI secure boot, you don't need to give everyone a secret key. You just need to give them a public key. It doesn't matter if someone can read that public key- you just can't let them [easily] change it.
I agree the on/off setting for secure boot should be locked down after boot, but the list of trusted certificates is explicitly intended to be modifiable after boot. It's basically implemented with UEFI authenticated variables (i.e., signed variables). The OS (or some application running on the OS), it supposed to be able to overwrite an authenticated variable by supplying a new, properly signed string. The UEFI BIOS will verify the signature on the newly supplied string prior to overwriting the variable.
Then I have great news for you! At least, for your first wish. If all you want is a TPM-based trusted boot, then you can do that today. A TPM-based trusted boot just stores hashes of the BIOS, option ROMs, boot loader, etc., executed during boot. You can later access those hashes, and report the hashes to another server (signed by the TPM, of course, so you can't fake them).
UEFI secure boot doesn't use a TPM. The UEFI BIOS will verify option ROMs and boot loaders prior to executing them. A TPM isn't very useful for doing that, and therefore isn't used. Of course, if there is a TPM, Microsoft will happily store hashes of its critical system files on the TPM during the boot process, and it can access those hashes (and hashes the BIOS, opROMs, etc.) later on.
Your second wish is possible, but don't hold your breath.
The rogue CA demonstration attack on MD5 was important. It showed the attack wasn't entirely theoretical. Some thought that even though you could find collisions in MD5 easily enough, you wouldn't be able to find meaningful collisions that could be used an attack. This demonstration showed you could do a real attack without needing a ridiculous amount of processing power.
However, as Mathinker said, the weaknesses in MD5 and SHA-1 really aren't problems at all for password hashing. Collision attacks don't help you invert hash functions- preimage attacks do. There aren't any serious preimage attacks on MD5 or SHA-1. There's a theoretical preimage attack against MD5, but from a practical perspective its probably much slower than brute-force search.
Also, salted hashes only help you so much. Yes, they help block attacks using rainbow tables, but was was described in this article was just a regular old brute force search without the use of rainbow tables. So, for an attack like this, salted hashes don't make it any more difficult for an attacker to get one password, but it would make it more difficult for an attacker to invert a bunch of hashed passwords from a stolen password database.
Strictly speaking, NIST still allows the use of SHA-1 for password hashing. NIST says you shouldn't use SHA-1 for anything that requires collision resistance. Password hashing doesn't require collision resistance, it only requires preimage resistance. In fact, there's relatively little benefit to using SHA-256 or SHA-512 for password hashing, since they're not that much slower than SHA-1 and its not much harder to generate and store a SHA-2 rainbow table than a SHA-1 rainbow table.
The page you referenced is from 2006, and NIST has backed off on their warnings about SHA-1 a little bit. The collision attack on SHA-1 probably isn't as bad as it looked in 2006. The attack hasn't improved- some of the alleged improved attacks turned out to have errors in them. No one has ever found a collision using SHA-1. Some people aren't even sure the claimed collision attack even works, though the general agreement is that even if the specific attack outlined in Wang's paper doesn't work, there probably is a similar one that does work.
In the mid 2000's the cryptographic community just saw both of the widely used hash functions attacked- SHA-1 and MD5. There were a lot of people concerned that the attacks would soon be catastrophic. That certainly didn't come true with SHA-1, and its only partially true with MD5 (which still has decent preimage resistance).
Still, telling people to move to SHA-2 is good general-purpose advice. It can be tricky to determine when you need collision resistance and when preimage resistance will do.
You don't just hash a password when you you store a new password. You also have to hash the password every time a user logs in. Now I agree you could certainly increase the iteration count on passwords, but one full second of computation on a busy server isn't going to fly. Companies have pushed back over far less. It has taken a long time to get where we are today when it comes to using TLS for login pages, and that's far less than one second of computation. Far fewer companies continue to use TLS once you get off the login page, even though the symmetric encryption operations that take place after the initial key establishment are even less computationally intensive.
I was just the example of twice the work to show how much easier it is to make brute-forcing a key infeasible versus brute-forcing a password. Yes, I'm sure you can do more than twice the work. But you're not going to get away with doing 3 billion clock cycles. I think you'd have a hard time getting people to deploy enough iterations to block brute-forcing attacks. And even if you do, it would be short-term fix. Bumping up the key length of an encryption algorithm can extend security a long time. From a practical perspective, AES-256 should work indefinitely, as long as someone doesn't break the algorithm itself. There's probably not enough energy in the universe to brute-force a 256-bit key, and quantum computers don't help that much. Bumping up the iteration count by a factor of 50 or so (any more and I think you'd have a hard time getting people to deploy it) basically just gets you the same thing as another character in the password. That's not enough to block these attacks. And by the time you'd actually get that deployed password crackers would be even more powerful. And since you can't get companies to change crypto algorithms and protocols constantly, you'd basically be stuck with that for 5-10 years.
You're not going to close hole with higher iteration counts alone.
It's not that simple. Cryptography is an asymmetric game: you always have to assume the attacker has orders of magnitude more computing resources than the target. Cryptography works because we can (usually) find problems that get exponentially harder and harder to crack. For instance, let's say you just want to encrypt something. A block cipher with a 64-bit key is just on the edge of being brute-forcible today. But, as a general rule, you could use a block cipher with a 128-bit key and it should only be half as fast as the 64-bit cipher (note I said this is a general rule, there are number of factors that influence speed). A 128-bit block cipher is 2^64 times more difficult to crack than a 64-bit block cipher. So, the target can make something 2^64 times more difficult to crack by just doing twice the work.
Your proposed solution just grows linearly, not exponentially. If you iterate SHA-1 10,000 times instead of just 5,000 you're also doing twice the work, but this time you've only made your password twice as difficult to crack. If you can suddenly start doing twice the work you did before, you have to assume the attackers can as well.
Yes, iterating hash functions buys us more time, but this is a game that targets can't win. Plus, you're ignoring all of the problems associated with moving to higher iteration counts. Probably first and foremost is interoperability. There's a massive application base out there that just uses MD5 or SHA1 with little to no iteration. It's not easy for software like Windows to change. I think it wasn't until Vista that Microsoft stopped storing a LAN Manager hash of users' passwords, which made then trivial to break. That's been known to be bad for a long, long time. Plus, in most web-based applications its not the client that does the hash operation, its the server. While your new Core i5 processor could probably easily handle bumping up the iteration count by an order of magnitude or so, Google's Gmail servers probably can't.
Longer, more complicated passwords would be more effective than increasing iteration counts, but people are bad at generating and remembering long passwords. So, the only long term solution seems to be moving to stronger forms of authentication, like smart cards or using devices like smart phones as one-time password devices.
School policies are usually pretty benign. Most of the time there's nothing wrong with the language of a policy per se, but they are often quite vague. And 99% of the time it's fine that a given policy is vague, since reasonable people are perfectly capable of looking at a situation and coming up with a reasonable response (and yes, school administrators are usually reasonable people).
But, when people get put on the defensive, they'll often try to justify their actions. Vaguely written policies are very easy to point to as justification. So, while I basically agree that school policies are generally reasonable, I'm far less inclined to say a student necessarily did something wrong just because he violated a policy. It's certainly possible that we're not getting the whole story here, but it seems like what we do know from the article points to authorities attempting to justify their actions. The article said the student was "very cooperative" with authorities, which to me suggests he didn't say anything like "It's a bomb!", or that he talked back to the vice principal or authorities.
And, for what it's worth, I don't think the response to the device was entirely unreasonable. I just think the vice principal and authorities should feel a little more embarrassed given what had actually happened.
That's why I think people shouldn't criticize the vice principal too much for calling authorities to look into this. He wouldn't have done so unless he thought there was a reasonable chance that this thing was a bomb. Maybe he should have known better, but he didn't, and I'm not going to fault him for erring on the side of caution. But, I am troubled that the school and authorities seem to be blaming the kid and parents for this, like they should have known better than to bring a geeky home project to a *technology magnet school*. I would consider this a non-story if the school, vice principal, and authorities showed a little embarrassment over this situation, but they really seem to think this family did something horribly wrong.
I agree it's sort of hard to know one way or the other, but I think the author of the article is implying the student and parents need counseling so this sort of thing doesn't happen again. The article's statement about counseling was stated right after it discussed the fire officials searching the home for explosives. And, it was in the same paragraph that said the student wasn't going to be prosecuted, but violated school policies. The article does talk about the student and parents being upset, but that's a little later in the article.
Maybe the author of the article is misleading us, but (somewhat uncharacteristically) Slashdot's summary seems to be pretty accurate.
I think I might know why we're disagreeing. MPEG can mean lots and lots of things. As we already know, its often used to describe a codec and a container. But really, there are multiple containers that sometimes go by MPEG for short, since they all come out of the MPEG standard.
There's the MPEG version 1 container, which Quicktime does support out-of-the-box. Then there's the MPEG-Program Stream container, which I thought was the same thing until today (it might just be a that these are different versions of a similar type, basically MPEG-1-PS and MPEG-2-PS, but I'm not sure). However, Quicktime cannot read MPEG-PS files. There's also the MPEG-Transport Stream, although that usually doesn't get confused with the other two as much, since it usually doesn't have a .mpg extension.
Its my understanding that Perian doesn't add support for any of these containers. Quicktime includes support for MPEG-1-PS. Apple's Quicktime MPEG Component adds support for both the MPEG2 decoder and the MPEG-2-PS container. But, as far as I know, there's no way to get support for MPEG-Transport Streams. Apple explicitly says they don't support it.
In addition, Final Cut Pro includes the Apple Quicktime MPEG Component. So, if you're able to play back mpg files, its probably because either they're not MPEG-PS files, or it's because you already have the MPEG component installed.
I came to this conclusion by trying to play back different .mpg files, and using MediaInfo to figure out what the format/container was used for each file. Then I did some searching online to make sure what I found was consistent with the MPEG page on Wikipedia, Apple's MPEG Component page, and Perian's page.
Does that sound right to you?