Professor proves NAND mirroring attack thwarts iPhone 5c security protocols

Posted:
in General Discussion edited September 2016
A Cambridge computer scientist used $100 of hardware to clone an iPhone 5c's NAND memory chip in a successful attempt at bypassing the handset's encryption lock, seemingly proving correct theories lobbed in the aftermath of Apple's encryption fight with the FBI.


Source: iFixit


As reported by the BBC, University of Cambridge professor Sergei Skorobogatov worked for four months on a NAND cloning and passcode testing rig to successfully bypass the security protocols Apple built into iPhone 5c. That same phone model was at the heart of a contentious debate between Apple and the U.S. government concerning the public's right to encryption.

Last week, Skorobogatov published his findings in a research paper and posted a proof-of-concept video of the process to YouTube. In practice, the method thwarts Apple's passcode counter, which limits the number and frequency of passcode attempts to safeguard against brute force attacks. An iPhone can also be configured to wipe its onboard data cache after a certain number of unsuccessful tries.

To circumvent Apple's protections, the professor first desoldered the handset's NAND flash chip and reverse engineered Apple's proprietary bus protocol, the latter of which is used to communicate with the A6 processor. Using an external harness connected to the A6 SoC, Skorobogatov was able to run through the maximum number of passcode entry attempts on a first NAND chip, then swap in a fresh NAND clone and try again.

"Because I can create as many clones as I want, I can repeat the process many many times until the passcode is found," he said.

A four-digit passcode took about 40 hours to crack, Skorobogatov said, adding that a six-digit code could take hundreds of hours. Apple estimated similar numbers when the FBI obtained a court order forcing Apple to access an iPhone 5c tied to last year's San Bernardino terror attack.



At the time, FBI and U.S. Justice Department experts claimed unlock methods like NAND mirroring are ineffective against Apple's built-in security protocols. To gain access to potential mission critical data, Apple would need to engineer a bespoke bypass tool, the FBI said. Security researchers theorized that NAND mirroring was a viable attack vector, but cautioned against the hardware-based hack, citing a high potential for data loss.

Apple fought the U.S. government's unlock request in a highly public court battle, saying the bypass tool would undeniably create a backdoor, thereby putting millions of iOS devices at risk. Discussion ended when the FBI commissioned technology from a third party to crack into the target iPhone.

As for Skorobogatov's NAND mirroring technique, the professor says the procedure can be applied to more recent iPhone models like the iPhone 6. Those claims are questionable, however, as the iPhone 5c was the last iPhone to go into production without Touch ID and corresponding Secure Enclave technology, both of which offer hardened protection against hacks.
«13

Comments

  • Reply 1 of 41
    Didn't we ALREADY know that. I actually knew that without even trying (because I'm a computer engineer).
    That; why Apple changed it later.
    It's not an easy attack though; if a person is doing that to your phone, I'm guessing you can spring for an Iphone 7...
    baconstangDeelronmike1jbdragonjony0
  • Reply 2 of 41
    I don't think there was any debate over whether this approach could be used to bypass the soft-counter in the 5c and 5 and earlier iPhone models. It's just time consuming and potentially not even useful since the device itself could harbour secondary encryption which would not be switched off by the operating system. (Not to forget remote-wipe facilities which may do significant harm before being able to be addressed.) As for the 5s, 6 and beyond: bypassing the counter on devices with the secure enclave is not trivial and even gaining access to the chip to read its data is likely to damage it beyond use.
    baconstanglolliverDeelroncapasicumwatto_cobrapscooter63jbdragonbigjony0
  • Reply 3 of 41
    I agree with foggyhill and EsquireCats. It's going to scaremonger people as well that don't understand that this type of attack can't work on those devices with a SecureEnclave.
    capasicumwatto_cobrajbdragonbigjony0
  • Reply 4 of 41
    lkrupplkrupp Posts: 6,940member
    And the typical user should be worried about this because...?
    lolliveranantksundaramwatto_cobrabigjony0
  • Reply 5 of 41
    lkrupp said:
    And the typical user should be worried about this because...?
    because... they shouldn't be. That's not the point of this article.
    gatorguybigjony0
  • Reply 6 of 41
    misamisa Posts: 827member
    Here's the question I really want to ask.

    Wouldn't this NAND mirroring attack work on most/all Android devices since they seem to prefer emulating the security (cloud storage of payment credentials for example) rather than actually having it?

    doctor davidcapasicumwatto_cobrabigjony0
  • Reply 7 of 41
    Apple should lower the password (code) minimum to 1 in hopes that all terrorists (and government officials) opt for single digit passwords.  
  • Reply 8 of 41
    Rayz2016Rayz2016 Posts: 4,561member
    lkrupp said:
    And the typical user should be worried about this because...?
    The typical user shouldn't be worried about this. However, the typical user should worried that the FBI is either lying or incompetent. 
    capasicumpscooter63rockdaddy22jasenj1theunfetteredmindbig
  • Reply 9 of 41
    SoliSoli Posts: 8,748member
    A four-digit passcode took about 40 hours to crack, Skorobogatov said, adding that a six-digit code could take hundreds of hours. Apple estimated similar numbers when the FBI obtained a court order forcing Apple to access an iPhone 5c tied to last year's San Bernardino terror attack. 
    1) I wonder how long that takes when you enable a complex passcode that uses the entirety of the Apple keyboard? Let's say a 6-character word using letters, numbers, and punctuation.

    2) Can this system even discern that the system wants complex over simple? I assume there would be an unprotected marker since the iOS keyboard changes to account for this change.
  • Reply 10 of 41
    What I find interesting is that Apple did not promote any new security features in the A10 or iOS 10. Unlikely that new features don't exist, just that Apple is keeping them close to the vest. It's doubtful that something new wasn't introduced.
    watto_cobrapscooter63bigjony0
  • Reply 11 of 41
    croprcropr Posts: 924member
    frxntier said:
    lkrupp said:
    And the typical user should be worried about this because...?
    because... they shouldn't be. That's not the point of this article.
    I would not be so sure about that.  The next time the FBI wants to read the data of an IPhone,  which could be yours, they will know where the professor lives
  • Reply 12 of 41
    Soli said:
    A four-digit passcode took about 40 hours to crack, Skorobogatov said, adding that a six-digit code could take hundreds of hours. Apple estimated similar numbers when the FBI obtained a court order forcing Apple to access an iPhone 5c tied to last year's San Bernardino terror attack. 
    1) I wonder how long that takes when you enable a complex passcode that uses the entirety of the Apple keyboard? Let's say a 6-character word using letters, numbers, and punctuation.

    2) Can this system even discern that the system wants complex over simple? I assume there would be an unprotected marker since the iOS keyboard changes to account for this change.
    Using all the character keys on the keyboard, there are (46*2) to the 6th power or 606,355,001,344 combinations.  Wonder how long it would take to find the password.  I also used the special characters.  46 keys plus using the shift key thus 46 * 2.
  • Reply 13 of 41
    foggyhill said:
    Didn't we ALREADY know that. I actually knew that without even trying (because I'm a computer engineer).
    That; why Apple changed it later.
    It's not an easy attack though; if a person is doing that to your phone, I'm guessing you can spring for an Iphone 7...
    If Apple were aware that the data could be extracted from the 5c using that technique why did they refuse to help the FBI and insist that the only way to extract the data would require custom code that could fall into the hands of criminals?

    Apple could have helped the FBI and then said "sorry guys, as much as we'd like to, we can't help you with any newer handsets" . Doing so would have been likely to have strengthened their case against future law enforcement demands and saved the public purse a shed load of money.
  • Reply 14 of 41
    SoliSoli Posts: 8,748member
    macseeker said:
    Soli said:
    A four-digit passcode took about 40 hours to crack, Skorobogatov said, adding that a six-digit code could take hundreds of hours. Apple estimated similar numbers when the FBI obtained a court order forcing Apple to access an iPhone 5c tied to last year's San Bernardino terror attack. 
    1) I wonder how long that takes when you enable a complex passcode that uses the entirety of the Apple keyboard? Let's say a 6-character word using letters, numbers, and punctuation.

    2) Can this system even discern that the system wants complex over simple? I assume there would be an unprotected marker since the iOS keyboard changes to account for this change.
    Using all the character keys on the keyboard, there are (46*2) to the 6th power or 606,355,001,344 combinations.  Wonder how long it would take to find the password.  I also used the special characters.  46 keys plus using the shift key thus 46 * 2.
    You don't use a special character or two since it's so easy to evoke on iOS and macOS keyboards? Since I rarely have to input my passcode too often on iOS due to Touch ID, I'm fine with having a very complex passcode.
    edited September 2016 watto_cobra
  • Reply 15 of 41
    lkrupp said:
    And the typical user should be worried about this because...?
    Think he tries to prove that FBI is an idiot for not using this method on San Bernadino murderer's phone when suggested, but wasting time went after Apple. 
    edited September 2016 watto_cobrajasenj1nolamacguytheunfetteredmindDeelron
  • Reply 16 of 41
    hungover said:
    foggyhill said:
    Didn't we ALREADY know that. I actually knew that without even trying (because I'm a computer engineer).
    That; why Apple changed it later.
    It's not an easy attack though; if a person is doing that to your phone, I'm guessing you can spring for an Iphone 7...
    If Apple were aware that the data could be extracted from the 5c using that technique why did they refuse to help the FBI and insist that the only way to extract the data would require custom code that could fall into the hands of criminals?

    Apple could have helped the FBI and then said "sorry guys, as much as we'd like to, we can't help you with any newer handsets" . Doing so would have been likely to have strengthened their case against future law enforcement demands and saved the public purse a shed load of money.
    No, what it proves is that the FBI never needed Apple's help at all. That the FBI's attempt to coerce a
    Apple was just to set a precedent so Apple couldn't refuse to help them in the future.

    That's also why the FBI used a phone in PR that they knew had absolutely nothing of value on it.
    MacPropscooter63rockdaddy22nolamacguytheunfetteredmindDeelronbig
  • Reply 17 of 41
    4a6d65 said:
    I agree with foggyhill and EsquireCats. It's going to scaremonger people as well that don't understand that this type of attack can't work on those devices with a SecureEnclave.
    Why not? The Secure Enclave is not changed in this case. Hence, UID/GID used to wrap the protection class keys are valid. And the data to be read in NAND is unchanged.

    I would argue that unless the Secure Enclave is using also the NAND device ID in its data protection, this method should work as well.
    What am I missing...
  • Reply 18 of 41
    SoliSoli Posts: 8,748member
    qweèéêëēėęrtyÿuûüùúūiîïíīįìoôöòóœøōõp
    aàáâäæãåāsßśšdfghjklł 
    zžźżxcçćčvbnñńm

    QWEÈÉÊËĒĖĘRTYŸUÛÜÙÚŪIÎÏÍĪĮÌOÔÖÒÓŒØŌÕP
    AÀÁÂÄÆÃÅĀSŚŠDFGHJKLŁ
    ZŽŹŻXCÇĆČNÑŃM

    1234567890 °
    -/:;()$&@" –—• \ ₽¥€¢£₩ § ”“„»«
    .,?!' … ¿ ¡ ’‘`

    []{}#%^*+= ‰
    _\|~<>€£¥•
    Space Bar

    I count 180. That's a lot of options even before you consider that's only for the US English keyboard, that emoji are Unicode which could be added at anytime to the complexity of the keyboard options, along with many other characters.

    180^n is a lot. Even a 4 character passcode is over 1 billion options.
    edited September 2016 radarthekat
  • Reply 19 of 41
    Soli said:
    a–z = 26
    A–Z = 26
    0–9 = 10
    e + 7
    y + 1
    u + 5
    i + 6
    o + 8
    a + 8
    s + 3
    l + 1
    z + 3
    c + 3
    n + 2
    E + 7
    Y + 1
    U + 5
    I + 6
    O + 8
    A + 8
    S + 2
    L + 1
    Z + 3
    C + 3
    N + 2
    0 + 1
    - + 3
    / + 1
    $ + 6
    & + 1
    " + 5
    . + 1
    ? + 1
    ! + 1
    ' + 3
    % + 1
    Space Bar = 1


    qwertyuiop èéêëēėę ÿ ûüùúū îïíīįì ôöòóœøōõ
    asdfghjkl àáâäæãåā ßśš ł 
    zxcvbnm žźż çćč ñń

    QWERTYUIOP ÈÉÊËĒĖĘ Ÿ ÛÜÙÚŪ ÎÏÍĪĮÌ ÔÖÒÓŒØŌÕ
    ASDFGHJKL ÀÁÂÄÆÃÅĀ ŚŠ Ł
    ZXCVBNM ŽŹŻ ÇĆČ ÑŃ

    1234567890 °
    -/:;()$&@" –—• \ ₽¥€¢£₩ § ”“„»«
    .,?!' … ¿ ¡ ’‘`

    []{}#%^*+= ‰
    _\|~<>€£¥•
    Space Bar

    That's a lot of options even before you consider emoji is Unicode and could be added at anytime to the complexity of the keyboard options, along with many other characters.
    A strong password would help, yes.
    That is regardless of with/without Secure Enclave.
    watto_cobra
  • Reply 20 of 41
    nclman said:
    4a6d65 said:
    I agree with foggyhill and EsquireCats. It's going to scaremonger people as well that don't understand that this type of attack can't work on those devices with a SecureEnclave.
    Why not? The Secure Enclave is not changed in this case. Hence, UID/GID used to wrap the protection class keys are valid. And the data to be read in NAND is unchanged.

    I would argue that unless the Secure Enclave is using also the NAND device ID in its data protection, this method should work as well.
    What am I missing…

    The time delayed after every missed guess. That is built into the secure enclave, not the OS, and does not reset when the limit is reached and the data is deleted in the NAND. And does not reset after rebooting the iPhone. When a new clone NAND is put in after 10 guesses, the time delay remains and guesses can only be inputed at a rate of  maybe 1 every hour (or so).  So theoretically, this technique may work, but it will take a lot, lot, lot, lot, lot, longer to brute force the code. So even a 4 digit passcode may take years to hack. 
    edited September 2016 watto_cobrapscooter63redraider11radarthekatnclman
Sign In or Register to comment.