Or is it completely, 100% open source such that I can compile my own boot loader and sign it with my own key and install it myself?
Yes.
The Android verified boot specification requires that unlockable devices allow you to install your own verification key, to verify your own system images. Boot loaders mostly aren't open source, unfortunately, so it'll be an OEM-provided bootloader that's using your key. Google is working on that. The starting point is the new Pixel C tablet, which uses ChromiumOS's open source boot loader, so the full stack is open (though there are still bits of closed firmware, sigh).
Oh, and note that I said *unlockable* devices. Verified boot will cause non-unlockable devices to be even harder to muck with. I'm actually hopeful that this will increase the availability of unlockable devices by increasing demand for them. We'll see if it works out that way.
That's one approach. Another is that we could dump all this H1B crap and just issue work visas to anyone who wants to come. That's my preference, though I'm one of those wild-eyed libertarians who doesn't believe that where you were born should affect where you are allowed work. Crazy, I know.
I'm gone a bit too cynical to think this is an altruistic effort by Google to protect De People from the government spying on them. Could it just be an attempt to make their DRM more robust?
No, this doesn't do anything to improve the DRM, which is already done in a separate secure OS that has always been cryptographically verified by the bootloader.
tell the Judge that if he wants this information, he can pony up the several million dollars it would take to extract the key.
Sorry, should have responded to this as well. Even if you do the EFM attack, it won't cost several million dollars. You can rent the time required on the necessary equipment for a few thousand dollars, at most. Many grad students could get it for free.
I specifically recall an article about a guy using an electron microscope to retrieve information like this.
Electron force microscopy is one way, but there are others, some that are much cheaper and more accessible. I may be giving a Black Hat talk next year about one of them, so I won't say any more for the moment:)
Long story short, PIN codes and such aren't long enough to be cryptologically secure so if you can copy the state you can brute force it easily. So what happens is you have a trusted chip that takes a PIN on one end, returns the AES key to decrypt on the other end. This chip has a countdown so if you enter the wrong PIN too many times, it'll wipe the key. It's also tamper-proof so if you try to open up the chip and alter the countdown or read the key directly it'll self-destruct. Essentially Apple is using the same kind of chip as "Trusted Computing"/"Secure Boot" uses to protect the private keys, nobody is supposed to be able to be extract them.
It's not quite that good. Secure Enclave isn't a separate chip, and it's not tamper-reactive. Secure Enclave is Apple's application of ARM's TrustZone, which provides a secure virtual CPU. Everything runs on the main CPU, but in a mode that provides access to all of the hardware, while the normal OS is restricted in what it can access. For example, pages of memory can be marked secure, in which case the MMU will not allow the normal (non-secure) OS to access them.
Done right, TrustZone is invulnerable to software-based attacks and can be somewhat resistant to hardware-based attacks.
The fact that the H1-B program requires the visa holders to be paid the prevailing wage. Oh, sure, that's what it says on paper, but since it's almost never enforced (a claim which can be substantiated by the fact that US employers are willing to participate in the program, which would not happen if they couldn't pay these people less) it's meaningless. Perhaps some companies (like yours) play by the rules and pay the H1-Bs the same as a native worker, but I would bet the farm that 99% of all H1-B visa holders in the USA are paid at least 10-20% below the true "prevailing wage".
There's two flaws here. 1: When your device is encrypted on KitKat and below, you must enter the decryption password to boot. So no remote access unless the device is already running (which it probably is, but still). I don't know if Lollipop and above are different since I keep encryption off in favor of speed.
The same is true on Lollipop and Marshmallow. Note that on KitKat and below, breaking the device decryption is not terribly hard, since most user passwords are weak, for convenience. What you do is:
1. Access the flash directly. The easiest way is probably to desolder it from the device and pop it into another device.
2. Read the crypto footer on the data partition. This contains the disk encryption key (DEK), encrypted with a key encryption key (KEK) derived from your password with scrypt.
3. Brute force the password to recover the KEK, and then the DEK. Scrypt should be tuned to take about one second per password, but that's one second on the device. Because you can do this step off-device, you can throw massive hardware at it. Though you probably don't need much against a four-digit PIN.
On Lollipop and Marshmallow it's a little harder, because if your device has hardware-backed credentials, a hardware-based 2048-bit RSA key is used in the KEK derivation process. The key derivation function (KDF) consists of scrypt applied to your password, then an RSA signature of the output, then scrypt of the signature. This is an odd KDF, but prior to Marshmallow, RSA was basically the only hardware-based algorithm available (starting with Marshmallow we now have ECDSA, AES and HMAC in hardware). So to most efficiently brute force the password, you can offload the scrypt operations to big hardware, but you must do the RSA on the device, which rate-limits your attempts.
The rate-limiting isn't very strong in Lollipop; a Nexus 6 can do 20 hardware-based RSA signing operations per second. Still, it provides a lower bound on brute force times. Not one that matters given a four-digit PIN, (10^4 / 20 / 60 / 2 = 4.2 minutes, on average), but a six-character alphanumeric password becomes quite secure (36^6 / 20 / 60 / 60 / 24 / 365 / 2 = 1.7 years, on average).
The rate-limiting is a bit better in Marshmallow. Rather than relying on the speed of the hardware to limit brute force, we have the hardware impose a one-second wait time between operations with the RSA key. Time to crack a four-digit PIN doesn't get much better (10^4 / 60 / 2 = 83 minutes, on average), but a good six-character password becomes all but uncrackable (34.5 years, on average).
I can't give any details, but I want to make it much stronger yet in N.
2. You can install all the apps you want remotely, but they must be launched by the user at least once before they can start running any background processes. There was an exploit in Android 2.1 and below that allowed an app to run immediately, and there was a "locate my phone" tool that exploited exactly this so you could install it remotely AFTER losing your phone, but it no longer works.
Also, apps can't unlock the phone anyway. The GP is assuming Apple has access to some iOS APIs that can do this, but that seems unlikely to me.
On Android you can browse the Play Market on a desktop-browser and remotely install applications on your phone, with no confirmation or anything needed on the phone.
That only helps if apps can unlock the device. They can't on Android, and I see no reason why they'd be able to on iOS, either.
What makes you think that book is valid? Authors have to eat and are well known for their hyperbolic spinning of facts to get dead tree material off shelves.
How about because many of the key players in the events described have publicly supported the descriptions of the events as written, even though those events don't always paint them in the most positive light?
Really, there comes a point where cynicism is just another way of fooling yourself into believing comfortable lies.
"Command and Control" is an excellent book. I highly recommend it. And it makes clear that the notions of safety and control we apply to nuclear weapons today were not applied until well into the 80s, and the military (especially Air Force and Navy) really fought the imposition of safety measures and positive control. It really is pretty amazing that we made it through the Cold War without any unintended nuclear detonations.
Top startups are paying pretty damn well, so this has nothing to do with not paying enough. I work for Google and we lose engineers to them all the time despite already paying these people well.
Yep. The challenge for companies like Google (my employer also) is that they can't offer the candidate a chance at becoming a multi-millionaire, and the startups can. Google can offer to pay $200K in salary + bonus + stock grants, but a startup can offer $100K + stock options that will probably expire worthless, but have a non-negligible chance of being worth $50M. Especially for younger engineers who don't yet need to support family, etc., it makes a lot of sense to hop from startup to startup for a few years, just to see if they strike it rich.
We also pay exactly the same salaries for US citizens as we do for foreigners, their immigration status has no impact on pay.
The H1B program requires that. I suspect a lot of lower-tier companies do actually find ways to work around it, but I really doubt any of the big players do. It's too much risk over what is -- to the company -- a fairly trivial amount of money. Google expects to generate revenues of about $1M for each employee, so it makes no sense to engage in legally-risky behaviors to save, say $30K in salary.
I strongly suspect that H1B hires cost Google more than a similarly-qualified US citizen, because in addition to paying the same salary, the company also has to spend a lot of money on the legal processes, plus international relocation, etc.
It's actually a pretty simple mathematical fact that if whenever you find a good candidate, the candidate has a bunch of competing offers, then there are more open positions than there are applicants.
Exactly. When you need to hire 1000 (say) excellent engineers per year, but your recruiters can only find 10 qualified local candidates per week, you have to cast a wider net.
and you're absolutely wrong that I could take out a bunch of innocent folks without feeling a thing, regardless of weapon.
Well, not you, personally, but a kook with a Maschinenpistole can do a lot of damage with very little training. They only get into trouble when it jams, and they need to clear the weapon.
When I first fired a MAC-10.45 ACP, I was surprised how easy that thing handled.
But did you actually spend any time trying to hit targets? The "spray of bullets" method is actually dramatically less effective in the real world, even against a crowd, than people expect. Barring extreme training, full auto really only has one application, and that's convincing someone who is shooting at you to take cover, because without extensive training you can't hit the broad side of a barn with a fully-automatic rifle and machine pistols are even worse. Actual machine guns are different; they have the weight to be controllable.
With sufficient training, you can learn to fire controlled bursts, all the way down to single shots, with a fully-automatic rifle or machine pistol. But your kook will not have that. Most professional soldiers don't have that much training, which is why many militaries have moved away from full-auto small arms, preferring select-fire weapons that support single shot and small burst modes.
If I were a terrorist leader and I wanted to send a kook to deliver maximum damage in a crowded place (and didn't have a bomb, which is really the ideal option), I'd give him an extremely reliable medium-power semi-auto rifle and spend time training him to aim carefully and change magazines quickly. A semi-automatic AK, with a folding stock, probably. I would not give him an MP7. He'd empty the magazine in less than a second, hitting maybe three or four people with a 30-round magazine, leaving him fumbling to change magazines and giving even unarmed people an easy chance to tackle him and take him out.
I don't think Google places that much emphasis on stack rankings. My managers have always described them as primarily a tie-breaking tool, when, employees are close to some boundary based on their peer feedback.
I suppose it might be a problem if an engineer's work was so isolated that he or she didn't have enough peers to get feedback from. It's hard to see how that could happen in Google's organizational structure, though.
I work remotely, for Google, and get good performance reviews. I suppose one counterexample doesn't necessarily destroy your claim, but it does call it into question.
Isn't sleeping under your desk while your code is compiling allowed or even encouraged at Google?
Sure it's allowed, though the sleep pods would be a better place, and if you did it very much your co-workers would wonder why you're not getting enough sleep at home. If it's because you're not going home at a reasonable hour, your manager will probably talk to you about the importance of work/life balance (not because you're sleeping at work, but because you're not going home; time away from work is important).
There have been some issues with employees trying to live on campus, though, especially with interns who are far from home and don't really have anything better to do. Some pushed it so far that I believe there's actually an official policy stating that employees must go home at night. Or so I've heard, anyway. I've never actually found it in any official documentation.
Hunting rifles are not elephant guns, and many of them can break down nicely, especially sportsterized versions with shorter barrels. Also, MP7s do not have a "clip", and you're absolutely wrong that I could take out a bunch of innocent folks without feeling a thing, regardless of weapon.
It will turn your Kevlar vest into confetti. This is why the authorities everywhere in the world do not want to see fully automatic versions getting into the hands of private citizens and the black market.
Yer granddad's.30-06: 890 m/s. And, more importantly, 3820 J muzzle energy, as compared to 506 J for the MP7.
Or, if you want to get a little more modern, the 7mm Remington Magnum: 1100 m/s and 4057 J. Or there's the.338 Lapua: 1050 m/s and nearly 5000 J. Or... we could keep going up here.
Standard hunting rifles are dramatically more powerful than standard military small arms, because they're designed for shooting larger animals and because rapid fire is less important, so recoil can be much greater. All of which means that if you're concerned about the effectiveness of Kevlar vests against private citizens, you're not worried about military-style weapons.
I'm sure Google in the UK and Europe offers vacation that complies with expectations in that part of the world. Your expectations simply would not be met by US companies.
I like it because it doesn't create any wear on the USB connector.
It's also a nice solution for devices whose USB connectors are broken. For a lot of Android devices with removable batteries (not Nexus devices) you can get after-market charging antennas to install inside the back cover and make it possible to charge a device that would otherwise need a potentially-expensive repair.
Slashdot Mirror
Or is it completely, 100% open source such that I can compile my own boot loader and sign it with my own key and install it myself?
Yes.
The Android verified boot specification requires that unlockable devices allow you to install your own verification key, to verify your own system images. Boot loaders mostly aren't open source, unfortunately, so it'll be an OEM-provided bootloader that's using your key. Google is working on that. The starting point is the new Pixel C tablet, which uses ChromiumOS's open source boot loader, so the full stack is open (though there are still bits of closed firmware, sigh).
Oh, and note that I said *unlockable* devices. Verified boot will cause non-unlockable devices to be even harder to muck with. I'm actually hopeful that this will increase the availability of unlockable devices by increasing demand for them. We'll see if it works out that way.
That's one approach. Another is that we could dump all this H1B crap and just issue work visas to anyone who wants to come. That's my preference, though I'm one of those wild-eyed libertarians who doesn't believe that where you were born should affect where you are allowed work. Crazy, I know.
I'm gone a bit too cynical to think this is an altruistic effort by Google to protect De People from the government spying on them. Could it just be an attempt to make their DRM more robust?
No, this doesn't do anything to improve the DRM, which is already done in a separate secure OS that has always been cryptographically verified by the bootloader.
I also said that lots of companies work around it.
tell the Judge that if he wants this information, he can pony up the several million dollars it would take to extract the key.
Sorry, should have responded to this as well. Even if you do the EFM attack, it won't cost several million dollars. You can rent the time required on the necessary equipment for a few thousand dollars, at most. Many grad students could get it for free.
I specifically recall an article about a guy using an electron microscope to retrieve information like this.
Electron force microscopy is one way, but there are others, some that are much cheaper and more accessible. I may be giving a Black Hat talk next year about one of them, so I won't say any more for the moment :)
Long story short, PIN codes and such aren't long enough to be cryptologically secure so if you can copy the state you can brute force it easily. So what happens is you have a trusted chip that takes a PIN on one end, returns the AES key to decrypt on the other end. This chip has a countdown so if you enter the wrong PIN too many times, it'll wipe the key. It's also tamper-proof so if you try to open up the chip and alter the countdown or read the key directly it'll self-destruct. Essentially Apple is using the same kind of chip as "Trusted Computing"/"Secure Boot" uses to protect the private keys, nobody is supposed to be able to be extract them.
It's not quite that good. Secure Enclave isn't a separate chip, and it's not tamper-reactive. Secure Enclave is Apple's application of ARM's TrustZone, which provides a secure virtual CPU. Everything runs on the main CPU, but in a mode that provides access to all of the hardware, while the normal OS is restricted in what it can access. For example, pages of memory can be marked secure, in which case the MMU will not allow the normal (non-secure) OS to access them.
Done right, TrustZone is invulnerable to software-based attacks and can be somewhat resistant to hardware-based attacks.
The fact that the H1-B program requires the visa holders to be paid the prevailing wage. Oh, sure, that's what it says on paper, but since it's almost never enforced (a claim which can be substantiated by the fact that US employers are willing to participate in the program, which would not happen if they couldn't pay these people less) it's meaningless. Perhaps some companies (like yours) play by the rules and pay the H1-Bs the same as a native worker, but I would bet the farm that 99% of all H1-B visa holders in the USA are paid at least 10-20% below the true "prevailing wage".
That doesn't contradict what I said.
There's two flaws here. 1: When your device is encrypted on KitKat and below, you must enter the decryption password to boot. So no remote access unless the device is already running (which it probably is, but still). I don't know if Lollipop and above are different since I keep encryption off in favor of speed.
The same is true on Lollipop and Marshmallow. Note that on KitKat and below, breaking the device decryption is not terribly hard, since most user passwords are weak, for convenience. What you do is:
1. Access the flash directly. The easiest way is probably to desolder it from the device and pop it into another device.
2. Read the crypto footer on the data partition. This contains the disk encryption key (DEK), encrypted with a key encryption key (KEK) derived from your password with scrypt.
3. Brute force the password to recover the KEK, and then the DEK. Scrypt should be tuned to take about one second per password, but that's one second on the device. Because you can do this step off-device, you can throw massive hardware at it. Though you probably don't need much against a four-digit PIN.
On Lollipop and Marshmallow it's a little harder, because if your device has hardware-backed credentials, a hardware-based 2048-bit RSA key is used in the KEK derivation process. The key derivation function (KDF) consists of scrypt applied to your password, then an RSA signature of the output, then scrypt of the signature. This is an odd KDF, but prior to Marshmallow, RSA was basically the only hardware-based algorithm available (starting with Marshmallow we now have ECDSA, AES and HMAC in hardware). So to most efficiently brute force the password, you can offload the scrypt operations to big hardware, but you must do the RSA on the device, which rate-limits your attempts.
The rate-limiting isn't very strong in Lollipop; a Nexus 6 can do 20 hardware-based RSA signing operations per second. Still, it provides a lower bound on brute force times. Not one that matters given a four-digit PIN, (10^4 / 20 / 60 / 2 = 4.2 minutes, on average), but a six-character alphanumeric password becomes quite secure (36^6 / 20 / 60 / 60 / 24 / 365 / 2 = 1.7 years, on average).
The rate-limiting is a bit better in Marshmallow. Rather than relying on the speed of the hardware to limit brute force, we have the hardware impose a one-second wait time between operations with the RSA key. Time to crack a four-digit PIN doesn't get much better (10^4 / 60 / 2 = 83 minutes, on average), but a good six-character password becomes all but uncrackable (34.5 years, on average).
I can't give any details, but I want to make it much stronger yet in N.
2. You can install all the apps you want remotely, but they must be launched by the user at least once before they can start running any background processes. There was an exploit in Android 2.1 and below that allowed an app to run immediately, and there was a "locate my phone" tool that exploited exactly this so you could install it remotely AFTER losing your phone, but it no longer works.
Also, apps can't unlock the phone anyway. The GP is assuming Apple has access to some iOS APIs that can do this, but that seems unlikely to me.
On Android you can browse the Play Market on a desktop-browser and remotely install applications on your phone, with no confirmation or anything needed on the phone.
That only helps if apps can unlock the device. They can't on Android, and I see no reason why they'd be able to on iOS, either.
What, specifically, do you think I'm misperceiving?
Your experience is completely different from mine.
What makes you think that book is valid? Authors have to eat and are well known for their hyperbolic spinning of facts to get dead tree material off shelves.
How about because many of the key players in the events described have publicly supported the descriptions of the events as written, even though those events don't always paint them in the most positive light?
Really, there comes a point where cynicism is just another way of fooling yourself into believing comfortable lies.
"Command and Control" is an excellent book. I highly recommend it. And it makes clear that the notions of safety and control we apply to nuclear weapons today were not applied until well into the 80s, and the military (especially Air Force and Navy) really fought the imposition of safety measures and positive control. It really is pretty amazing that we made it through the Cold War without any unintended nuclear detonations.
Top startups are paying pretty damn well, so this has nothing to do with not paying enough. I work for Google and we lose engineers to them all the time despite already paying these people well.
Yep. The challenge for companies like Google (my employer also) is that they can't offer the candidate a chance at becoming a multi-millionaire, and the startups can. Google can offer to pay $200K in salary + bonus + stock grants, but a startup can offer $100K + stock options that will probably expire worthless, but have a non-negligible chance of being worth $50M. Especially for younger engineers who don't yet need to support family, etc., it makes a lot of sense to hop from startup to startup for a few years, just to see if they strike it rich.
We also pay exactly the same salaries for US citizens as we do for foreigners, their immigration status has no impact on pay.
The H1B program requires that. I suspect a lot of lower-tier companies do actually find ways to work around it, but I really doubt any of the big players do. It's too much risk over what is -- to the company -- a fairly trivial amount of money. Google expects to generate revenues of about $1M for each employee, so it makes no sense to engage in legally-risky behaviors to save, say $30K in salary.
I strongly suspect that H1B hires cost Google more than a similarly-qualified US citizen, because in addition to paying the same salary, the company also has to spend a lot of money on the legal processes, plus international relocation, etc.
It's actually a pretty simple mathematical fact that if whenever you find a good candidate, the candidate has a bunch of competing offers, then there are more open positions than there are applicants.
Exactly. When you need to hire 1000 (say) excellent engineers per year, but your recruiters can only find 10 qualified local candidates per week, you have to cast a wider net.
and you're absolutely wrong that I could take out a bunch of innocent folks without feeling a thing, regardless of weapon.
Well, not you, personally, but a kook with a Maschinenpistole can do a lot of damage with very little training. They only get into trouble when it jams, and they need to clear the weapon.
When I first fired a MAC-10 .45 ACP, I was surprised how easy that thing handled.
But did you actually spend any time trying to hit targets? The "spray of bullets" method is actually dramatically less effective in the real world, even against a crowd, than people expect. Barring extreme training, full auto really only has one application, and that's convincing someone who is shooting at you to take cover, because without extensive training you can't hit the broad side of a barn with a fully-automatic rifle and machine pistols are even worse. Actual machine guns are different; they have the weight to be controllable.
With sufficient training, you can learn to fire controlled bursts, all the way down to single shots, with a fully-automatic rifle or machine pistol. But your kook will not have that. Most professional soldiers don't have that much training, which is why many militaries have moved away from full-auto small arms, preferring select-fire weapons that support single shot and small burst modes.
If I were a terrorist leader and I wanted to send a kook to deliver maximum damage in a crowded place (and didn't have a bomb, which is really the ideal option), I'd give him an extremely reliable medium-power semi-auto rifle and spend time training him to aim carefully and change magazines quickly. A semi-automatic AK, with a folding stock, probably. I would not give him an MP7. He'd empty the magazine in less than a second, hitting maybe three or four people with a 30-round magazine, leaving him fumbling to change magazines and giving even unarmed people an easy chance to tackle him and take him out.
I don't think Google places that much emphasis on stack rankings. My managers have always described them as primarily a tie-breaking tool, when, employees are close to some boundary based on their peer feedback.
I suppose it might be a problem if an engineer's work was so isolated that he or she didn't have enough peers to get feedback from. It's hard to see how that could happen in Google's organizational structure, though.
I work remotely, for Google, and get good performance reviews. I suppose one counterexample doesn't necessarily destroy your claim, but it does call it into question.
Isn't sleeping under your desk while your code is compiling allowed or even encouraged at Google?
Sure it's allowed, though the sleep pods would be a better place, and if you did it very much your co-workers would wonder why you're not getting enough sleep at home. If it's because you're not going home at a reasonable hour, your manager will probably talk to you about the importance of work/life balance (not because you're sleeping at work, but because you're not going home; time away from work is important).
There have been some issues with employees trying to live on campus, though, especially with interns who are far from home and don't really have anything better to do. Some pushed it so far that I believe there's actually an official policy stating that employees must go home at night. Or so I've heard, anyway. I've never actually found it in any official documentation.
Hunting rifles are not elephant guns, and many of them can break down nicely, especially sportsterized versions with shorter barrels. Also, MP7s do not have a "clip", and you're absolutely wrong that I could take out a bunch of innocent folks without feeling a thing, regardless of weapon.
Heckler and Koch MP7: 735 m/s
It will turn your Kevlar vest into confetti. This is why the authorities everywhere in the world do not want to see fully automatic versions getting into the hands of private citizens and the black market.
Yer granddad's .30-06: 890 m/s. And, more importantly, 3820 J muzzle energy, as compared to 506 J for the MP7.
Or, if you want to get a little more modern, the 7mm Remington Magnum: 1100 m/s and 4057 J. Or there's the .338 Lapua: 1050 m/s and nearly 5000 J. Or... we could keep going up here.
Standard hunting rifles are dramatically more powerful than standard military small arms, because they're designed for shooting larger animals and because rapid fire is less important, so recoil can be much greater. All of which means that if you're concerned about the effectiveness of Kevlar vests against private citizens, you're not worried about military-style weapons.
Doze?
The ones I've seen, it attaches directly to the battery contacts.
No, but if I did my expectations wouldn't reduce.
I'm sure Google in the UK and Europe offers vacation that complies with expectations in that part of the world. Your expectations simply would not be met by US companies.
You don't work at a company in the US, do you?
I like it because it doesn't create any wear on the USB connector.
It's also a nice solution for devices whose USB connectors are broken. For a lot of Android devices with removable batteries (not Nexus devices) you can get after-market charging antennas to install inside the back cover and make it possible to charge a device that would otherwise need a potentially-expensive repair.