10 ms·

Insider Attack Resistance

126 points by el_duderino 8y ago

nmstoker 8y ago
Impressive, but given the prevalence of apps that demand full access to all USB contents and then arming the user with only the ability to accept or decline all-or-nothing, this seems like an electronic Maginot Line. But to be fair, they've got to start somewhere and there is always hope they'll extend the permissions options to be more powerful.
jakobegger 8y ago
> We recommend that all mobile device makers do the same. Kind of insencere when the biggest competitor has been doing this since 2013 (the feature is marketed as “secure enclave” by Apple)
- praptak 8y ago
  Does Apple market their solution as resistant to someone having all Apple's keys but not the user password?
  - ucaetano 8y ago
    Based on the San Bernardino case, no. It wasn't a matter of feasibility, Apple could have done it but refused to.
- mandevil 8y ago
  The Apple Secure Enclave cannot defend against someone who has the signing keys to the password software (or at least couldn't as of 2016)- that's why the FBI wanted Apple's "help" over the San Bernardino shooter. Apple said no, but could have done it- it was a policy choice of theirs to fight the FBI. Google has created a situation with the Pixel2 where they can't do that sort of thing even if they wanted to. And justified it without ever referencing "Search Warrants" or "Nation-state threat actors" even though that is the obvious driving force here.
  - deleted 8y ago
    [deleted]
  - saurik 8y ago
    > ...or at least couldn't as of 2016... The iPhone 5c came out in 2013 (and was a budget device based on the hardware design from 2012; the iPhone 5s--which I believe, though would happily be proved wrong, had already fixed this issue--actually came out at the same time as the iPhone 5c). I have no love for Apple (clearly), and I think they (and, sadly, the EFF) were being disincenuous at the time about the definition of "back door", but you are just spreading misinformation here: "as of 2016" would imply the iPhone 7 was vulnerable, which is a much newer device than the one from the infamous San Bernadino scenario :/.
    - kobayashi 8y ago
      >I have no love for Apple (clearly) For those who are unaware, Saurik created Cydia, the package manager for jailbroken iOS devices, as well as a whole bunch of jailbroken iOS-related software.
    - asfasgasg 8y ago
      So is the contention that Apple is already insider attack-resistant? Or is the contention merely that they might be?
  - jakobegger 8y ago
    The phone in San Bernardino case did not yet have the secure enclave.
- bitmapbrother 8y ago
  This is not simply about the presence of a "secure enclave" or security module as Google calls it. It's about preventing the firmware on the security module from being compromised without knowing the users password. To mitigate these risks, Google Pixel 2 devices implement insider attack resistance in the tamper-resistant hardware security module that guards the encryption keys for user data. This helps prevent an attacker who manages to produce properly signed malicious firmware from installing it on the security module in a lost or stolen device without the user's cooperation. Specifically, it is not possible to upgrade the firmware that checks the user's password unless you present the correct user password. There is a way to "force" an upgrade, for example when a returned device is refurbished for resale, but forcing it wipes the secrets used to decrypt the user's data, effectively destroying it.
  - jakobegger 8y ago
    Yes, I know. I thought that the secure enclave requires the user passcode to authorize an update, but after re-reading the iOS security whitepaper, I am no longer sure that this is actually correct. (it’s not mentioned anywhere) So while you do have to provide your passcode to update an iOS device, it could be that this requirement is only enforced at a higher level (ie. not by the secure enclave itself).
- wffurr 8y ago
  > biggest competitor You mean Samsung?
delvinj 8y ago
What if the attack is in the form of a court order?
- conradev 8y ago
  That's the same attack vector as far as this change is concerned. The idea is that nothing, not even Google, can change the change the firmware without first wiping the device or entering the passcode.
- ZeroCool2u 8y ago
  This constraint forces an attacker to focus on the user that actually has the password. From a security perspective, this forces the attacker to shift focus on forcing the user to reveal the secret as opposed to the company responsible for creating the firmware, in this case Google. My guess is in the U.S. the 4th and 5th amendment would prevent the government from forcing you to reveal the secret, so long as you do not rely on biometric security, which has been in some cases ruled as exempt from the same rights as say a password. IANAL though, so I really can't elaborate on an explanation of why. I think if anything you're likely to be held on obstruction charges or have your assets frozen in an attempt to apply pressure on someone unwilling to cooperate. In other, perhaps less forgiving locales like North Korea, China, or Russia, I imagine one may end up being the subject of persuasion of a more physical nature.
  - mtgx 8y ago
    > This constraint forces an attacker to focus on the user that actually has the password. The irony is that while the Android development team is doing this, the Google business and cloud services teams are increasingly gathering more data from the Android users, and encouraging them to put as much of their data on Google's servers as possible. And Google can give access to that data because it doesn't use end-to-end or homomorphic encryption.
    - ucaetano 8y ago
      You'd need a court order to get that data from Google, but not to get the data from a seized phone. That court order might also be challenged by Google. That applies especially to non-law enforcement actors. Those can't get a court order to force Google to hand over the data.
ISL 8y ago
This is the sort of development that makes me want a Pixel 2. I've been leaning toward an iPhone, for the first time, on security grounds, so this is a welcome piece of news. Thanks, Google. Please keep it up.
- saagarjha 8y ago
  I'm pretty sure everything mentioned here has been a feature on iPhones for quite some time.
  - refulgentis 8y ago
    No
    - tptacek 8y ago
      I'm interested in which details you can present.
      - uncleamerica 8y ago
        No
      - joshuamorton 8y ago
        If I understand correctly, this feature want on phones as recently as 2016 (San Bernardino). It would have made it impossible for Apple to comply. I haven't seen anything since that says that this has changed, but I admit I don't pay close attention.
      - refulgentis 8y ago
        I'm interested in which details OP can present - I'm somewhat surprised to be put in a position where I have to do a breakdown of Apple's security vs. Google's to address a claim that doesn't have anything backing it, and is specifically stated with uncertainty ("I'm pretty sure...") I'm only _somewhat_ surprised because people have a high-level idea that Apple is the one manufacturer concerned with security, and I'm somewhat _surprised_ because tptacek is involved, and he's aware that it's highly unusual to request no proof from the original claim while asking people addressing it to provide proof. This contradiction leads me to believe tptacek has info on this that could settle things, leading me to resent facing two generations of posts that don't attempt to flesh out a claim while I'm downvoted for not fleshing out a claim, and I'm requested to make a claim. I'll keep eating downvotes instead, this is objectively unreasonable. EDIT: ...and there's already a sibling post that addresses this. Not a great look folks. :/
gustavmarwin 8y ago
The beauty of this can be seen by how those securities are leverage and enhanced on CopperheadOS. I criticise Google a lot for how much information they store on us, but this work they do both on Android (open-source) and the Pixel phones hardware should receive more praise.
gouggoug 8y ago
> There is a way to "force" an upgrade, for example when a returned device is refurbished for resale, but forcing it wipes the secrets used to decrypt the user's data, effectively destroying it. It's interesting. Why "[wipe] the secrets used to decrypt the user's data, effectively destroying it" instead of wiping the data itself too? Is this to potentially allow a third-party with enough power (i.e. a government entity) to eventually decrypt the data?
- mdellavo 8y ago
  this is the standard "remote wipe" technique and a standard cryptographic application
  - gouggoug 8y ago
    I know nothing about the "standard remote wipe technique", but neophyte me believes that wiping security keys isn't exactly protecting you against your data being eventually retrieved and decrypted.
    - kerng 8y ago
      Agreed. In security, time works against mitigations. If you want data to be gone, just deleting keys is a bit short sighted.
      - varenc 8y ago
        This wouldn’t really improve security. Only the secure hardware is secure from physical attack. The user data is encrypted and put on memory that isn’t physically secure. If you have a way to decrypt that data, you can just physically remove that memory, copy that data, and break the encryption on it. If people could break encryption, they wouldn’t go about updating the firmware and triggering a potential data wipe in the first place. In short, if you don’t trust encryption you’ve already lost.
        kerng 8y ago
dredmorbius 8y ago
Does the firmware signature preclude flasshing the devices with an alternate OS? (Considered independenttly of data stored.)
- ec109685 8y ago
  It wouldn’t be able to read the encrypted data.
  - dredmorbius 8y ago
    Which is why I specifically excluded that consideration.
- bitmapbrother 8y ago
  The locked bootloader would prevent flashing anything that was not signed by Google.
  - deleted 8y ago
    [deleted]
  - dredmorbius 8y ago
    :-(
smattiso 8y ago
Have there been notable cases of a malicious actor installing a compromised OS on a target's phone for spying purposes?
ec109685 8y ago
One attack this wouldn’t guard against is a malicious actor pushing a buggy version of the Secure Enclave code that couldn’t be updated without destroying all data on the phone.
tagtoc 8y ago
Or the motiviation is to relief Google of associated GDPR responsibilities. But it sure is an improvement for the end user.
vuluvu 8y ago
"To prevent attackers from replacing our firmware with a malicious version, we apply digital signatures." How about putting a read/write switch on the device that prevents writing to the firmware if the switch is in the off position.
- laggyluke 8y ago
  What problem would it solve?

126 points by el_duderino 8y ago

Impressive, but given the prevalence of apps that demand full access to all USB contents and then arming the user with only the ability to accept or decline all-or-nothing, this seems like an electronic Maginot Line. But to be fair, they've got to start somewhere and there is always hope they'll extend the permissions options to be more powerful.

jakobegger 8y ago

> We recommend that all mobile device makers do the same. Kind of insencere when the biggest competitor has been doing this since 2013 (the feature is marketed as “secure enclave” by Apple)

praptak 8y ago
Does Apple market their solution as resistant to someone having all Apple's keys but not the user password?
- ucaetano 8y ago
  Based on the San Bernardino case, no. It wasn't a matter of feasibility, Apple could have done it but refused to.
mandevil 8y ago
The Apple Secure Enclave cannot defend against someone who has the signing keys to the password software (or at least couldn't as of 2016)- that's why the FBI wanted Apple's "help" over the San Bernardino shooter. Apple said no, but could have done it- it was a policy choice of theirs to fight the FBI. Google has created a situation with the Pixel2 where they can't do that sort of thing even if they wanted to. And justified it without ever referencing "Search Warrants" or "Nation-state threat actors" even though that is the obvious driving force here.
- deleted 8y ago
  [deleted]
- saurik 8y ago
  > ...or at least couldn't as of 2016... The iPhone 5c came out in 2013 (and was a budget device based on the hardware design from 2012; the iPhone 5s--which I believe, though would happily be proved wrong, had already fixed this issue--actually came out at the same time as the iPhone 5c). I have no love for Apple (clearly), and I think they (and, sadly, the EFF) were being disincenuous at the time about the definition of "back door", but you are just spreading misinformation here: "as of 2016" would imply the iPhone 7 was vulnerable, which is a much newer device than the one from the infamous San Bernadino scenario :/.
  - kobayashi 8y ago
    >I have no love for Apple (clearly) For those who are unaware, Saurik created Cydia, the package manager for jailbroken iOS devices, as well as a whole bunch of jailbroken iOS-related software.
  - asfasgasg 8y ago
    So is the contention that Apple is already insider attack-resistant? Or is the contention merely that they might be?
- jakobegger 8y ago
  The phone in San Bernardino case did not yet have the secure enclave.
bitmapbrother 8y ago
This is not simply about the presence of a "secure enclave" or security module as Google calls it. It's about preventing the firmware on the security module from being compromised without knowing the users password. To mitigate these risks, Google Pixel 2 devices implement insider attack resistance in the tamper-resistant hardware security module that guards the encryption keys for user data. This helps prevent an attacker who manages to produce properly signed malicious firmware from installing it on the security module in a lost or stolen device without the user's cooperation. Specifically, it is not possible to upgrade the firmware that checks the user's password unless you present the correct user password. There is a way to "force" an upgrade, for example when a returned device is refurbished for resale, but forcing it wipes the secrets used to decrypt the user's data, effectively destroying it.
- jakobegger 8y ago
  Yes, I know. I thought that the secure enclave requires the user passcode to authorize an update, but after re-reading the iOS security whitepaper, I am no longer sure that this is actually correct. (it’s not mentioned anywhere) So while you do have to provide your passcode to update an iOS device, it could be that this requirement is only enforced at a higher level (ie. not by the secure enclave itself).
wffurr 8y ago
> biggest competitor You mean Samsung?

delvinj 8y ago

What if the attack is in the form of a court order?

conradev 8y ago
That's the same attack vector as far as this change is concerned. The idea is that nothing, not even Google, can change the change the firmware without first wiping the device or entering the passcode.
ZeroCool2u 8y ago
This constraint forces an attacker to focus on the user that actually has the password. From a security perspective, this forces the attacker to shift focus on forcing the user to reveal the secret as opposed to the company responsible for creating the firmware, in this case Google. My guess is in the U.S. the 4th and 5th amendment would prevent the government from forcing you to reveal the secret, so long as you do not rely on biometric security, which has been in some cases ruled as exempt from the same rights as say a password. IANAL though, so I really can't elaborate on an explanation of why. I think if anything you're likely to be held on obstruction charges or have your assets frozen in an attempt to apply pressure on someone unwilling to cooperate. In other, perhaps less forgiving locales like North Korea, China, or Russia, I imagine one may end up being the subject of persuasion of a more physical nature.
- mtgx 8y ago
  > This constraint forces an attacker to focus on the user that actually has the password. The irony is that while the Android development team is doing this, the Google business and cloud services teams are increasingly gathering more data from the Android users, and encouraging them to put as much of their data on Google's servers as possible. And Google can give access to that data because it doesn't use end-to-end or homomorphic encryption.
  - ucaetano 8y ago
    You'd need a court order to get that data from Google, but not to get the data from a seized phone. That court order might also be challenged by Google. That applies especially to non-law enforcement actors. Those can't get a court order to force Google to hand over the data.

ISL 8y ago

This is the sort of development that makes me want a Pixel 2. I've been leaning toward an iPhone, for the first time, on security grounds, so this is a welcome piece of news. Thanks, Google. Please keep it up.

saagarjha 8y ago
I'm pretty sure everything mentioned here has been a feature on iPhones for quite some time.
- refulgentis 8y ago
  No
  - tptacek 8y ago
    I'm interested in which details you can present.
    - uncleamerica 8y ago
      No
    - joshuamorton 8y ago
      If I understand correctly, this feature want on phones as recently as 2016 (San Bernardino). It would have made it impossible for Apple to comply. I haven't seen anything since that says that this has changed, but I admit I don't pay close attention.
    - refulgentis 8y ago
      I'm interested in which details OP can present - I'm somewhat surprised to be put in a position where I have to do a breakdown of Apple's security vs. Google's to address a claim that doesn't have anything backing it, and is specifically stated with uncertainty ("I'm pretty sure...") I'm only _somewhat_ surprised because people have a high-level idea that Apple is the one manufacturer concerned with security, and I'm somewhat _surprised_ because tptacek is involved, and he's aware that it's highly unusual to request no proof from the original claim while asking people addressing it to provide proof. This contradiction leads me to believe tptacek has info on this that could settle things, leading me to resent facing two generations of posts that don't attempt to flesh out a claim while I'm downvoted for not fleshing out a claim, and I'm requested to make a claim. I'll keep eating downvotes instead, this is objectively unreasonable. EDIT: ...and there's already a sibling post that addresses this. Not a great look folks. :/

gustavmarwin 8y ago

The beauty of this can be seen by how those securities are leverage and enhanced on CopperheadOS. I criticise Google a lot for how much information they store on us, but this work they do both on Android (open-source) and the Pixel phones hardware should receive more praise.

gouggoug 8y ago

> There is a way to "force" an upgrade, for example when a returned device is refurbished for resale, but forcing it wipes the secrets used to decrypt the user's data, effectively destroying it. It's interesting. Why "[wipe] the secrets used to decrypt the user's data, effectively destroying it" instead of wiping the data itself too? Is this to potentially allow a third-party with enough power (i.e. a government entity) to eventually decrypt the data?

mdellavo 8y ago
this is the standard "remote wipe" technique and a standard cryptographic application
- gouggoug 8y ago
  I know nothing about the "standard remote wipe technique", but neophyte me believes that wiping security keys isn't exactly protecting you against your data being eventually retrieved and decrypted.
  - kerng 8y ago
    Agreed. In security, time works against mitigations. If you want data to be gone, just deleting keys is a bit short sighted.
    - varenc 8y ago
      This wouldn’t really improve security. Only the secure hardware is secure from physical attack. The user data is encrypted and put on memory that isn’t physically secure. If you have a way to decrypt that data, you can just physically remove that memory, copy that data, and break the encryption on it. If people could break encryption, they wouldn’t go about updating the firmware and triggering a potential data wipe in the first place. In short, if you don’t trust encryption you’ve already lost.
      - kerng 8y ago

dredmorbius 8y ago

Does the firmware signature preclude flasshing the devices with an alternate OS? (Considered independenttly of data stored.)

ec109685 8y ago
It wouldn’t be able to read the encrypted data.
- dredmorbius 8y ago
  Which is why I specifically excluded that consideration.
bitmapbrother 8y ago
The locked bootloader would prevent flashing anything that was not signed by Google.
- deleted 8y ago
  [deleted]
- dredmorbius 8y ago
  :-(

smattiso 8y ago

Have there been notable cases of a malicious actor installing a compromised OS on a target's phone for spying purposes?

ec109685 8y ago

One attack this wouldn’t guard against is a malicious actor pushing a buggy version of the Secure Enclave code that couldn’t be updated without destroying all data on the phone.

tagtoc 8y ago

Or the motiviation is to relief Google of associated GDPR responsibilities. But it sure is an improvement for the end user.

vuluvu 8y ago

"To prevent attackers from replacing our firmware with a malicious version, we apply digital signatures." How about putting a read/write switch on the device that prevents writing to the firmware if the switch is in the off position.

laggyluke 8y ago
What problem would it solve?