First, keep in mind the WiFi Alliance isn't developing standards. The standards are developed in IEEE 802.11. The WiFi Alliance is basically creating a profile of the 802.11 standards that they'll cover as part of their certification program. Dragonfly is used because that's what's specified in 802.11.
Are there better ones? Perhaps, although Dragonfly has been around for a while and has been the subject of third-party analysis. There's something to be said for preferring an older scheme with well-understood implementation considerations (which you're calling "flaws") over newer proposals that might seem to have better properties, but whose implementations haven't been fully considered. In other words, prefer the devil you know.
Public key validation doesn't refer to a PKI. It just means when you're doing a Diffie-Hellman key exchange you should check that the public key you receive is in the subgroup its supposed to be in.
Honestly, I'm no expert in PAKEs, but a lot of them are built on Diffie-Hellman where this sort of check has been long known as needed depending on the group you're working in and whether its a static or ephemeral exchange. It seems disingenuous to call that a "flaw."
Some of the skepticism surrounding Dragonfly in practice seems to be more related to concerns with how the security review went down in the CFRG, and some connections to the NSA, than with the protocol itself. I understand there are other PAKEs that seem to have better security properties, like J-PAKE, but they all have other problems (JPAKE, for example, is rather slow). It's mostly a non-issue for the WiFi Alliance, as they have to work within what's supported in the IEEE specs (which basically means sticking with PSK or using Dragonfly), but I don't know why IEEE chose what they did.
I think you're greatly exaggerating the problems. If you do public key validation, as we've long known you should do to protect against these kinds of attacks, the problem goes away. Or, if you use safe-prime groups, as the community has moved to for DH, the problem pretty much goes away. It should go away for ECC groups, too.
While some people have mentioned the "US-resident traveling abroad" scenario, that's not really the scenario that is driving this backlash. It's mostly non-US residents wanting to subscribe to the US version of Netflix.
As a side note, I've done what you described. I have 75/75mbps on Verizon FiOS. Unfortunately, I rarely actually get 75mbps upload in practice- presumably only to services co-located with Verizon, or direct peering arrangements. I'm lucky to sustain 10mbps when VPNing from the US. In Europe, I'm lucky to sustain 2mbps.
Wait... Why can't VPNing be stopped? Sure, you're not going to be able to stop them all, but it seems quite feasible to block the vast majority of them.
First, for consumers to be able to find VPNs, they have to be publicly-available and advertised. What percentage of VPN services control 95% of market? A wild guess, but I would bet it isn't above 50, and very well might be below 10. Monitoring the top 100 services wouldn't require inordinate resources, in part because there's a wide range of companies interested in identifying and blocking VPN traffic for various reasons.
Second, if that fails, there are various techniques Netflix could use to attempt to detect VPN traffic using automated or semi-automated means. Netflix gets to see the requesting IP addresses for all their traffic. They even get to run run code on the client platforms, either because they (directly or indirectly) control the app used to access the content, or because they have the market share to put VPN-detection capabilities in the EME code for browsers. They can look at things like the number of different users connecting through the same IP address, ping/traceroute times, server and client-side IP address checks, etc., to heuristically detect VPN usage. None of those are going to be perfect, but Netflix benefits greatly by their size- they see a massive amount of traffic. If they use everything that is available to them, they can probably very accurately detect VPN usage.
Would they do it? Probably not, because Netflix is simply trying to show that they're doing due-diligence, and blocking using IP address blocks for known VPN services is sufficient for that. But, no, this isn't an impossible game of wack-a-mole for Netflix. Scale is on their side.
Yes, I read the article. I know what quote you're referring to from the article. I'm skeptical it means what the NY Times thinks it means. Getting anything through a standards process is "a challenge in finesse."
No, the article wasn't referring to AES. AES was developed by a pair of Belgian cryptographers as part of an open competition. The NSA approves the use of AES to protect Top Secret information. They didn't put a back door in AES.
The article was referring to the Dual Elliptic Curve Deterministic Random Bit Generator (Dual EC DRBG), published as part of SP800-90. The DRBG uses a set of constants, like many crypto algorithms. The NSA, as the designer of the DRBG, selected the constants. Microsoft researchers noted that if the constants were carefully chosen, the NSA could predict future outputs of the DRBG. Despite what the New York Time article says, the NSA probably didn't do that. No one was going to use this DRBG anyway, except for the NSA and their partners, so they would have very little reason to sneak in a backdoor. Still, it's a bad property to have in a crypto algorithm. You should really explain the provenance of any constants used in a crypto algorithm, and there was no explanation of how the Dual EC DRBG constants were selected.
It's not quite as bad as you're suggesting. You don't need to install a different DRM plugin for each content provider. You just need different plugins for different forms of DRM. At least in practice, I suspect, most users (i.e., those running common browsers and operating systems) won't have to install anything- the DRM plugins will ship with the browser. That's the case now with the Chromebooks and Windows 8.1/IE11.
Whether their terms are generous or not really depends on who you think is holding the cards. A company like Verizon expects to be paid for transit because historically they could demand it. A company wanting to interconnect didn't have a choice if they wanted to send data to them.
Verizon here is sort of a special case. They're an incredibly large ISP, and they own a Tier 1 network (though I wonder whether they exclusively use them). If they were a small ISP that had to pay to connect to a Tier 1 their perspective would be very different. But, Netflix is a special case too. They offer a service that's in high demand by Verizon customers. I suppose you're right that Netflix and Cogent are looking for special treatment, but that's because they think they are special. And they might be, at least from a negotiating perspective.
Now, apparently Netflix knows they're not powerful enough to demand agreements on their terms. I suppose too many people don't have more than one plausible option for an ISP, so taking a harder stance than what they've done with SuperHD would be dangerous. Still, I think they ought to do more. It seems silly for Netflix to directly or indirectly pay Verizon for the privilege of sending data to Verizon customers that requested it. If Netflix or Cogent wanted to send traffic *through* Verizon's network and onto another network that would be different. It seems like making the sender pay can really let the ISPs hide shady practices and put content providers in a difficult pricing situation. What if, for example, Comcast charged Netflix much cheaper rates to send data to their customers than Verizon? What can Netflix do? Do you expect Netflix to charge Verizon customers more for service than Comcast? Out of fairness I suppose they should, but that seems like a terrible outcome. It seems like it would be a much better outcome if Comcast/Verizon charged their customers based how much it actually cost them to deliver the data they requested. At least, I think that would clean up some of the perverse incentives that seem to exist in the current pricing structures.
I think the author is vastly overestimating the importance of the box. Sure, I'll grant you that the Apple boxes are nice, but the only people that get that attached to the box are people that are already attached to the device inside. And that's pretty common for iDevices.
By the way, I didn't have any problems opening the Nexus 7 box. I saw the funny video before I got my device, so I was probably compensating. At least, I had a knife to cut the tape holding the box shut. After that it was smooth sailing. I don't know why the reviewers had such a hard time. Maybe they just had performance anxiety by being on video.
Again, I'll grant that the de-boxing process wasn't as nice as my iPad's box, but it wasn't unpleasant by any means. On a scale from 1-10, with 10 being an iPad box and 1 being the stupid sealed plastic containers, I'd put it at about a 7. It wasn't particularly memorable, and that's probably fine.
Wouldn't the hospitals and doctors still have a profit motive? And, with health insurance policies typically set up so the individual see's little cost to themselves for procedures and tests, who would be providing a counterbalance to the doctors' profit motives to keep costs moderately sane?
I actually think the public option was a good idea, although mostly for folks that don't/can't get insurance through their employer. But I don't think it was actually going to help noticeably with costs.
You were already doing that before, partly through your taxes, partly through effectively paying higher amounts to hospitals, in order to compensate hospitals for the all the ER visits they get from people without insurance (and thus likely never pay). You potentially could have ended up in the situation you were worried about if the Supreme Court struck down the individual mandate, but kept the rest of the law.
How would a TPM do that? TPMs, for the most part, can just do things the main CPU asks it to do, like storing hashes or performing digital signature operations. TPMs can't, despite widespread FUD, interfere with software running on the main CPU. And it certainly can't stop malicious software from overwriting critical OS files.
Secure boot is absolutely effective without a TPM. It's largely independent. As you seem to know, UEFI Secure Boot does a verified boot- verifying signatures on code before executing it. Systems with TPMs do a measured boot- hashing any code executed during boot and storing the hash (no, TPMs won't stop you from running software).
Now, what Ubuntu is apparently trying to do defeats the purpose of UEFI secure boot. They must be locking GRUB2 down in some way. If GRUB2 is left wide open, then the signed Ubuntu first stage bootloader, combined with GRUB2, can bypass the UEFI secure boot mechanisms on everyones' machines. If an attacker starts doing that, the Ubuntu bootloader signature is going to be revoked.
The difficulty in that is that there are still a lot of PCI/PCIe cards out there that don't have UEFI option ROMs. Notably, you might want to use that 2-year old video card when your system is booting. Or, maybe you have an I/O card that you're booting off of. Certainly not everyone is going to need that, but enough users are going to be pretty upset (think: big enterprise customers with lots of users) that I don't think they could do that. However, before Microsoft announced the requirement that systems ship with a UEFI Secure Boot off-switch, I thought some laptops might ship without that option. Still, I think there are enough corporate customers running older Windows OSes or Linux on new systems that OEMs wouldn't do that. I don't think Microsoft is planning a patch to Win7 so that it works with Secure Boot enabled. A lot of corporate customers will be running that for a while.
How/why would the chainloaded [modified] Windows boot manager refuse to run? The way UEFI Secure Boot works is that the UEFI BIOS will verify the signature on an EFI executable prior to passing control to it. The UEFI BIOS largely relinquishes control of the system to the bootloader when it executes it. The bootloader will itself call the next piece of code that runs, not the UEFI BIOS, which is why the bootloader needs to do its own signature verification on the OS (or second stage bootloader) to maintain the trust chain. But, the bootloader absolutely could pass control to something without verifying its signature. And, if that's a maliciously modified Windows bootloader, that second bootloader could be designed to execute a maliciously modified Windows kernel without verifying its signature first.
I've been an unRAID user for a couple years now and I'm reluctant to to strongly recommend it. Lime Technology, the small company behind unRAID, seems to be a one-man show. And that one man seems to disappear for weeks or months at a time. If customer service and technical support are important to you, and you desire timely updates for new features and bug fixes, then unRAID might not be for you. I've largely lost confidence in the unRAID developer. unRAID v5 has been in beta for almost 2 years. At first it seemed like the developer was struggling to fix some compatibility problems that plagued recent releases, but more recent messages indicated that he wasn't paying attention to all the people complaining about those compatibility problems. Now that's he's finally listening to the bug reports things are looking up. He released V5 RC1 about a week ago, but pulled it down after a day due to the bug reports he received. But, a couple days later he posted a new version that seemed to clear up the major compatibility issues people were having for the last 6 months. That was great, although part of me is even more upset now that I know he could have easily fixed the bugs introduced in the betas 6 months ago if he had just listened to the beta testers.
Anyways, unRAID's features are a pretty good fit for the OP, but as an overall product it might not be great for his needs if he wants good support and updates.
You're right- I was wrong. I was thinking about QAM, where each QAM channel can support two HD channels (or 3, if you recompress the video like Comcast). I knew the bandwidth was essentially the same between QAM and ATSC channels, but I forgot that all the error correction drops the effective data rate from 36mbps to 19mbps. 19 would be enough to carry two H.264-compressed HD streams (which aren't widely used or supported for ATSC), but its not enough for 2 mpeg-2 streams.
Verizon's LTE coverage is actually pretty good. They cover lots of major cities, and since they're using a relatively low frequency, it penetrates walls and into buildings much, much, much better than Sprint/Clear's wimax coverage. Verizon claims to cover about 75% of the population with their current LTE deployment, which I believe based on the traveling I've done.
Of course, it seems sucks down the battery. That will be the case until LTE is everywhere, allowing Verizon to switch to Voice-over-LTE and turn off the CDMA radio in phones that have 4G coverage. Right now you always need the CDMA radio on if you want to be able to get calls.
He's probably counting the subchannels. For instance, a lot the major networks have 2-4 programs sharing the same channel. One digital TV channel is perfectly capable of handling 2 HD streams, or more if you use SD streams. So, a lot of networks will have one HD channel, and one or more SD channels airing stuff like weather, maybe a simulcast of the HD stream in SD, and possibly a third SD stream that just airs weird stuff.
25 channels seems like plenty to me. There's only 5-8 major networks (depending on what you consider 'major'), whose affiliates are collectively probably responsible for 98% of what is watched. A single digital channel can carry two HD channels, so 25 channels can carry up to 50 HD programs. That would push the smaller guys out, sure, but I think it is worth it to free up some spectrum for wireless Internet. There's only so much spectrum that is suitable for wireless Internet- it basically needs to be below 2600Mhz to have much of a chance at penetrating walls, and things around 700-1000Mhz do much, much better. Digital television is sitting on some of the most desirable spectrum out there, and quite frankly, a lot of it is being wasted right now.
First, the UEFI secure boot requirement is mainly for client systems. Microsoft is making it optional for servers, and many won't implement it for legacy support reasons. But perhaps even more relevant, the MS requirements definitely don't apply to the types of servers you have in mind, which rarely come with an OS installed.
Second, I suspect many, if not most, rackmount servers still undergo a provisioning process whereby each server is individually configured some minimal amount. Some probably already have to have their BIOSes configured for various reasons. So, for systems destined to run Linux, it can be disabled (if someone can't manage to sign GRUB). For systems that will run Windows, it can stay enabled. Actually, a third situation is probably even more likely- a server destined to run a hypervisor. Given how much VMWare and Citrix care about security, I'm sure they'll support signed bootloaders once servers start supporting UEFI secure boot.
Third, the types of servers that really aren't ever touched come with BMCs with nearly unfettered access to system settings, including BIOS. Even though its a bit of a security vulnerability, I'm sure BMCs will be able to disable UEFI secure boot on server systems.
Security features should always default to on- particularly ones suitable for 99% of users.
What are you needing to mass deploy? What situation do you have in mind where a corporation has deployed a bunch of Win8 machines with UEFI secure boot enabled, and then later needs to push out an update that will break the machines?
Windows boxes, which will make up the vast majority of clients being remotely managed, will definitely work with secure boot enabled. So, unless you put in a old add-in card (which require physical presence anyway), what system change will interfere with secure boot? You're not pushing out Linux installs and GRUB remotely, are you? Because it seems like that's the only thing that might not play well with secure boot.
You obviously have a strong background in this area. I don't do BIOS development myself, but I do know people that do, and they always corrected me when I said SMI was part of BIOS. I definitely see your argument, but I still think you shouldn't consider it part of BIOS because it executes in SMSM. SMM is very different from the other modes on an Intel CPU. Real and protected modes (and the numerous other modes) aren't logically separated in the same way that SMM is separated from every other mode.
I kind of assumed you were imagining using a timer or hijacking some other frequently-needed SMI. I can imagine how that could work, but it doesn't seem practical to regularly halt execution to enter SM, perform security checks on whatever is in memory, and then resume execution. Wouldn't you have to, at least, inspect everything in memory? That would be quite slow.
Slashdot Mirror
First, keep in mind the WiFi Alliance isn't developing standards. The standards are developed in IEEE 802.11. The WiFi Alliance is basically creating a profile of the 802.11 standards that they'll cover as part of their certification program. Dragonfly is used because that's what's specified in 802.11.
Are there better ones? Perhaps, although Dragonfly has been around for a while and has been the subject of third-party analysis. There's something to be said for preferring an older scheme with well-understood implementation considerations (which you're calling "flaws") over newer proposals that might seem to have better properties, but whose implementations haven't been fully considered. In other words, prefer the devil you know.
Public key validation doesn't refer to a PKI. It just means when you're doing a Diffie-Hellman key exchange you should check that the public key you receive is in the subgroup its supposed to be in.
Honestly, I'm no expert in PAKEs, but a lot of them are built on Diffie-Hellman where this sort of check has been long known as needed depending on the group you're working in and whether its a static or ephemeral exchange. It seems disingenuous to call that a "flaw."
Some of the skepticism surrounding Dragonfly in practice seems to be more related to concerns with how the security review went down in the CFRG, and some connections to the NSA, than with the protocol itself. I understand there are other PAKEs that seem to have better security properties, like J-PAKE, but they all have other problems (JPAKE, for example, is rather slow). It's mostly a non-issue for the WiFi Alliance, as they have to work within what's supported in the IEEE specs (which basically means sticking with PSK or using Dragonfly), but I don't know why IEEE chose what they did.
I think you're greatly exaggerating the problems. If you do public key validation, as we've long known you should do to protect against these kinds of attacks, the problem goes away. Or, if you use safe-prime groups, as the community has moved to for DH, the problem pretty much goes away. It should go away for ECC groups, too.
While some people have mentioned the "US-resident traveling abroad" scenario, that's not really the scenario that is driving this backlash. It's mostly non-US residents wanting to subscribe to the US version of Netflix.
As a side note, I've done what you described. I have 75/75mbps on Verizon FiOS. Unfortunately, I rarely actually get 75mbps upload in practice- presumably only to services co-located with Verizon, or direct peering arrangements. I'm lucky to sustain 10mbps when VPNing from the US. In Europe, I'm lucky to sustain 2mbps.
Wait... Why can't VPNing be stopped? Sure, you're not going to be able to stop them all, but it seems quite feasible to block the vast majority of them.
First, for consumers to be able to find VPNs, they have to be publicly-available and advertised. What percentage of VPN services control 95% of market? A wild guess, but I would bet it isn't above 50, and very well might be below 10. Monitoring the top 100 services wouldn't require inordinate resources, in part because there's a wide range of companies interested in identifying and blocking VPN traffic for various reasons.
Second, if that fails, there are various techniques Netflix could use to attempt to detect VPN traffic using automated or semi-automated means. Netflix gets to see the requesting IP addresses for all their traffic. They even get to run run code on the client platforms, either because they (directly or indirectly) control the app used to access the content, or because they have the market share to put VPN-detection capabilities in the EME code for browsers. They can look at things like the number of different users connecting through the same IP address, ping/traceroute times, server and client-side IP address checks, etc., to heuristically detect VPN usage. None of those are going to be perfect, but Netflix benefits greatly by their size- they see a massive amount of traffic. If they use everything that is available to them, they can probably very accurately detect VPN usage.
Would they do it? Probably not, because Netflix is simply trying to show that they're doing due-diligence, and blocking using IP address blocks for known VPN services is sufficient for that. But, no, this isn't an impossible game of wack-a-mole for Netflix. Scale is on their side.
Yes, I read the article. I know what quote you're referring to from the article. I'm skeptical it means what the NY Times thinks it means. Getting anything through a standards process is "a challenge in finesse."
No, the article wasn't referring to AES. AES was developed by a pair of Belgian cryptographers as part of an open competition. The NSA approves the use of AES to protect Top Secret information. They didn't put a back door in AES.
The article was referring to the Dual Elliptic Curve Deterministic Random Bit Generator (Dual EC DRBG), published as part of SP800-90. The DRBG uses a set of constants, like many crypto algorithms. The NSA, as the designer of the DRBG, selected the constants. Microsoft researchers noted that if the constants were carefully chosen, the NSA could predict future outputs of the DRBG. Despite what the New York Time article says, the NSA probably didn't do that. No one was going to use this DRBG anyway, except for the NSA and their partners, so they would have very little reason to sneak in a backdoor. Still, it's a bad property to have in a crypto algorithm. You should really explain the provenance of any constants used in a crypto algorithm, and there was no explanation of how the Dual EC DRBG constants were selected.
It's not quite as bad as you're suggesting. You don't need to install a different DRM plugin for each content provider. You just need different plugins for different forms of DRM. At least in practice, I suspect, most users (i.e., those running common browsers and operating systems) won't have to install anything- the DRM plugins will ship with the browser. That's the case now with the Chromebooks and Windows 8.1/IE11.
Whether their terms are generous or not really depends on who you think is holding the cards. A company like Verizon expects to be paid for transit because historically they could demand it. A company wanting to interconnect didn't have a choice if they wanted to send data to them.
Verizon here is sort of a special case. They're an incredibly large ISP, and they own a Tier 1 network (though I wonder whether they exclusively use them). If they were a small ISP that had to pay to connect to a Tier 1 their perspective would be very different. But, Netflix is a special case too. They offer a service that's in high demand by Verizon customers. I suppose you're right that Netflix and Cogent are looking for special treatment, but that's because they think they are special. And they might be, at least from a negotiating perspective.
Now, apparently Netflix knows they're not powerful enough to demand agreements on their terms. I suppose too many people don't have more than one plausible option for an ISP, so taking a harder stance than what they've done with SuperHD would be dangerous. Still, I think they ought to do more. It seems silly for Netflix to directly or indirectly pay Verizon for the privilege of sending data to Verizon customers that requested it. If Netflix or Cogent wanted to send traffic *through* Verizon's network and onto another network that would be different. It seems like making the sender pay can really let the ISPs hide shady practices and put content providers in a difficult pricing situation. What if, for example, Comcast charged Netflix much cheaper rates to send data to their customers than Verizon? What can Netflix do? Do you expect Netflix to charge Verizon customers more for service than Comcast? Out of fairness I suppose they should, but that seems like a terrible outcome. It seems like it would be a much better outcome if Comcast/Verizon charged their customers based how much it actually cost them to deliver the data they requested. At least, I think that would clean up some of the perverse incentives that seem to exist in the current pricing structures.
I think the author is vastly overestimating the importance of the box. Sure, I'll grant you that the Apple boxes are nice, but the only people that get that attached to the box are people that are already attached to the device inside. And that's pretty common for iDevices.
By the way, I didn't have any problems opening the Nexus 7 box. I saw the funny video before I got my device, so I was probably compensating. At least, I had a knife to cut the tape holding the box shut. After that it was smooth sailing. I don't know why the reviewers had such a hard time. Maybe they just had performance anxiety by being on video.
Again, I'll grant that the de-boxing process wasn't as nice as my iPad's box, but it wasn't unpleasant by any means. On a scale from 1-10, with 10 being an iPad box and 1 being the stupid sealed plastic containers, I'd put it at about a 7. It wasn't particularly memorable, and that's probably fine.
Wouldn't the hospitals and doctors still have a profit motive? And, with health insurance policies typically set up so the individual see's little cost to themselves for procedures and tests, who would be providing a counterbalance to the doctors' profit motives to keep costs moderately sane?
I actually think the public option was a good idea, although mostly for folks that don't/can't get insurance through their employer. But I don't think it was actually going to help noticeably with costs.
You were already doing that before, partly through your taxes, partly through effectively paying higher amounts to hospitals, in order to compensate hospitals for the all the ER visits they get from people without insurance (and thus likely never pay). You potentially could have ended up in the situation you were worried about if the Supreme Court struck down the individual mandate, but kept the rest of the law.
How would a TPM do that? TPMs, for the most part, can just do things the main CPU asks it to do, like storing hashes or performing digital signature operations. TPMs can't, despite widespread FUD, interfere with software running on the main CPU. And it certainly can't stop malicious software from overwriting critical OS files.
Actually, it's a one-time $99 fee to sign an unlimited number of binaries.
Secure boot is absolutely effective without a TPM. It's largely independent. As you seem to know, UEFI Secure Boot does a verified boot- verifying signatures on code before executing it. Systems with TPMs do a measured boot- hashing any code executed during boot and storing the hash (no, TPMs won't stop you from running software).
Now, what Ubuntu is apparently trying to do defeats the purpose of UEFI secure boot. They must be locking GRUB2 down in some way. If GRUB2 is left wide open, then the signed Ubuntu first stage bootloader, combined with GRUB2, can bypass the UEFI secure boot mechanisms on everyones' machines. If an attacker starts doing that, the Ubuntu bootloader signature is going to be revoked.
The difficulty in that is that there are still a lot of PCI/PCIe cards out there that don't have UEFI option ROMs. Notably, you might want to use that 2-year old video card when your system is booting. Or, maybe you have an I/O card that you're booting off of. Certainly not everyone is going to need that, but enough users are going to be pretty upset (think: big enterprise customers with lots of users) that I don't think they could do that. However, before Microsoft announced the requirement that systems ship with a UEFI Secure Boot off-switch, I thought some laptops might ship without that option. Still, I think there are enough corporate customers running older Windows OSes or Linux on new systems that OEMs wouldn't do that. I don't think Microsoft is planning a patch to Win7 so that it works with Secure Boot enabled. A lot of corporate customers will be running that for a while.
How/why would the chainloaded [modified] Windows boot manager refuse to run? The way UEFI Secure Boot works is that the UEFI BIOS will verify the signature on an EFI executable prior to passing control to it. The UEFI BIOS largely relinquishes control of the system to the bootloader when it executes it. The bootloader will itself call the next piece of code that runs, not the UEFI BIOS, which is why the bootloader needs to do its own signature verification on the OS (or second stage bootloader) to maintain the trust chain. But, the bootloader absolutely could pass control to something without verifying its signature. And, if that's a maliciously modified Windows bootloader, that second bootloader could be designed to execute a maliciously modified Windows kernel without verifying its signature first.
I've been an unRAID user for a couple years now and I'm reluctant to to strongly recommend it. Lime Technology, the small company behind unRAID, seems to be a one-man show. And that one man seems to disappear for weeks or months at a time. If customer service and technical support are important to you, and you desire timely updates for new features and bug fixes, then unRAID might not be for you. I've largely lost confidence in the unRAID developer. unRAID v5 has been in beta for almost 2 years. At first it seemed like the developer was struggling to fix some compatibility problems that plagued recent releases, but more recent messages indicated that he wasn't paying attention to all the people complaining about those compatibility problems. Now that's he's finally listening to the bug reports things are looking up. He released V5 RC1 about a week ago, but pulled it down after a day due to the bug reports he received. But, a couple days later he posted a new version that seemed to clear up the major compatibility issues people were having for the last 6 months. That was great, although part of me is even more upset now that I know he could have easily fixed the bugs introduced in the betas 6 months ago if he had just listened to the beta testers.
Anyways, unRAID's features are a pretty good fit for the OP, but as an overall product it might not be great for his needs if he wants good support and updates.
You're right- I was wrong. I was thinking about QAM, where each QAM channel can support two HD channels (or 3, if you recompress the video like Comcast). I knew the bandwidth was essentially the same between QAM and ATSC channels, but I forgot that all the error correction drops the effective data rate from 36mbps to 19mbps. 19 would be enough to carry two H.264-compressed HD streams (which aren't widely used or supported for ATSC), but its not enough for 2 mpeg-2 streams.
Verizon's LTE coverage is actually pretty good. They cover lots of major cities, and since they're using a relatively low frequency, it penetrates walls and into buildings much, much, much better than Sprint/Clear's wimax coverage. Verizon claims to cover about 75% of the population with their current LTE deployment, which I believe based on the traveling I've done.
Of course, it seems sucks down the battery. That will be the case until LTE is everywhere, allowing Verizon to switch to Voice-over-LTE and turn off the CDMA radio in phones that have 4G coverage. Right now you always need the CDMA radio on if you want to be able to get calls.
Sure, but how many of those people are watching the major networks? You don't even need 25 digital channels to provide those.
He's probably counting the subchannels. For instance, a lot the major networks have 2-4 programs sharing the same channel. One digital TV channel is perfectly capable of handling 2 HD streams, or more if you use SD streams. So, a lot of networks will have one HD channel, and one or more SD channels airing stuff like weather, maybe a simulcast of the HD stream in SD, and possibly a third SD stream that just airs weird stuff.
25 channels seems like plenty to me. There's only 5-8 major networks (depending on what you consider 'major'), whose affiliates are collectively probably responsible for 98% of what is watched. A single digital channel can carry two HD channels, so 25 channels can carry up to 50 HD programs. That would push the smaller guys out, sure, but I think it is worth it to free up some spectrum for wireless Internet. There's only so much spectrum that is suitable for wireless Internet- it basically needs to be below 2600Mhz to have much of a chance at penetrating walls, and things around 700-1000Mhz do much, much better. Digital television is sitting on some of the most desirable spectrum out there, and quite frankly, a lot of it is being wasted right now.
First, the UEFI secure boot requirement is mainly for client systems. Microsoft is making it optional for servers, and many won't implement it for legacy support reasons. But perhaps even more relevant, the MS requirements definitely don't apply to the types of servers you have in mind, which rarely come with an OS installed.
Second, I suspect many, if not most, rackmount servers still undergo a provisioning process whereby each server is individually configured some minimal amount. Some probably already have to have their BIOSes configured for various reasons. So, for systems destined to run Linux, it can be disabled (if someone can't manage to sign GRUB). For systems that will run Windows, it can stay enabled. Actually, a third situation is probably even more likely- a server destined to run a hypervisor. Given how much VMWare and Citrix care about security, I'm sure they'll support signed bootloaders once servers start supporting UEFI secure boot.
Third, the types of servers that really aren't ever touched come with BMCs with nearly unfettered access to system settings, including BIOS. Even though its a bit of a security vulnerability, I'm sure BMCs will be able to disable UEFI secure boot on server systems.
Security features should always default to on- particularly ones suitable for 99% of users.
What are you needing to mass deploy? What situation do you have in mind where a corporation has deployed a bunch of Win8 machines with UEFI secure boot enabled, and then later needs to push out an update that will break the machines?
Windows boxes, which will make up the vast majority of clients being remotely managed, will definitely work with secure boot enabled. So, unless you put in a old add-in card (which require physical presence anyway), what system change will interfere with secure boot? You're not pushing out Linux installs and GRUB remotely, are you? Because it seems like that's the only thing that might not play well with secure boot.
You obviously have a strong background in this area. I don't do BIOS development myself, but I do know people that do, and they always corrected me when I said SMI was part of BIOS. I definitely see your argument, but I still think you shouldn't consider it part of BIOS because it executes in SMSM. SMM is very different from the other modes on an Intel CPU. Real and protected modes (and the numerous other modes) aren't logically separated in the same way that SMM is separated from every other mode.
I kind of assumed you were imagining using a timer or hijacking some other frequently-needed SMI. I can imagine how that could work, but it doesn't seem practical to regularly halt execution to enter SM, perform security checks on whatever is in memory, and then resume execution. Wouldn't you have to, at least, inspect everything in memory? That would be quite slow.