Difference between revisions of "GID Key"

From The iPhone Wiki
Jump to: navigation, search
(added new CPU)
m
 
(34 intermediate revisions by 8 users not shown)
Line 1: Line 1:
  +
The '''GID key''' ('''Group ID key''') is a 256-bit [[wikipedia:Advanced Encryption Standard|AES]] key shared by all devices with the same application processor. The GID key is part of how iOS encrypts software on the device ([https://books.google.com/books?id=CEzB2avQjR4C&lpg=PA268&vq=gid%20key&dq=GID%20Key&pg=PA268#v=onepage&q&f=false more explanation]). This is one component of the iOS security system, which also includes [[SHSH]] signatures.
The hardware AES key shared by every iDevice. This key differs between the [[S5L8900]], [[S5L8720]], [[S5L8920]], [[S5L8922]], [[S5L8930]], [[S5L8940]] and any other application processors.
 
   
  +
This key is different on each [[Application Processor|processor model]] ([[wikipedia:System on a chip|system on a chip]]) - in other words, the [[S5L8900]] (chip for iPhone 3G for example) has a different key compared to the [[S5L8930]] (A4 chip for iPhone 4, iPod touch (4th generation), etc.). On [[S5L8960]] and later processors, the [[Secure Enclave]] has it's own GID that is separate from the AP's which is used to encrypt the SEP Firmware before delivery to the end user.
It was used to generate [[AES Keys|Key 0x837]].
 
   
  +
Apple explains GID keys in its official [https://www.apple.com/br/privacy/docs/iOS_Security_Guide_Oct_2014.pdf iOS security guide] (page 9, chapter "Encryption and Data Protection"), along with [[UID key]]s:
==Attack==
 
  +
<blockquote>"The device’s unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused (UID) or compiled (GID) into the application processor during manufacturing. No software or firmware can read them directly; they can see only the results of encryption or decryption operations performed using them. The UID is unique to each device and is not recorded by Apple or any of its suppliers. The GID is common to all processors in a class of devices (for example, all devices using the Apple A8 processor), and is used as an additional level of protection when delivering system software during installation and restore. Integrating these keys into the silicon helps prevent them from being tampered with or bypassed, or accessed outside the AES engine. The UID and GID are also not available via JTAG or other debugging interfaces."</blockquote>
It would be great to perform some [http://en.wikipedia.org/wiki/Side_channel_attack side channel attack] on this to extract it.
 
  +
  +
On [[S5L8900]], the GID key was used to generate [[AES Keys#Key 0x837|AES Key 0x837]], used as the encryption key for [[S5L File Formats#IMG2|IMG2 files]]. With the introduction of [[IMG3 File Format|IMG3]] in iOS 2.0, iOS started using [[KBAG]]s instead of the 0x837 key. iOS 7.0 introduced the [[IM4P File Format]] and [[IMG4 File Format]] for [[A7]] and newer devices.
  +
  +
In [[iOS]] 3.0GM/3.0, a pseudo GID Key was used, which allowed getting [[Firmware Keys|firmware decryption keys]] for these firmwares without the device and with tools such as GitKeys or OpenSSL. See [[Decrypting Firmwares#S5L8900]].
  +
  +
== Potential attacks ==
  +
A hypothetical way to extract this key could be to perform some sort of [[wikipedia:side-channel attack|side-channel attack]] (see also [[Talk:GID Key]] for more speculation about potential attacks).
  +
  +
A presentation from May/June 2011 that explains a variety of attacks aiming to get this kind of information out of a chip: [http://www.cl.cam.ac.uk/~sps32/ECRYPT2011_1.pdf Fault attacks on secure chips: from glitch to flash (Part 1)] and [http://www.cl.cam.ac.uk/~sps32/ECRYPT2011_2.pdf Side-channel attacks: new directions and horizons (Part 2)].
  +
  +
Research into AES key extraction using side-channel analysis, done from 2010 to 2012: [http://www.cl.cam.ac.uk/~sps32/qvl_proj.html developing new technology for efficient side-channel analysis] - using a tool from [http://www.quovadislabs.com/ Quo Vadis Labs].
  +
  +
=== CIA research into attacks ===
  +
[https://firstlook.org/theintercept/2015/03/10/ispy-cia-campaign-steal-apples-secrets/ According to this {{date|2015|03}} article in ''The Intercept''] based on documents provided by Edward Snowden, the CIA has been particularly interested in figuring out how to extract GID keys as part of their efforts to get access to modifying iOS to insert spy software and to research further vulnerabilities:
  +
  +
<blockquote>"At the 2011 Jamboree conference, there were two separate presentations on hacking the GID key on Apple’s processors. One was focused on non-invasively obtaining it by studying the electromagnetic emissions of — and the amount of power used by — the iPhone’s processor while encryption is being performed. Careful analysis of that information could be used to extract the encryption key. Such a tactic is known as a "side channel" attack. The second focused on a "method to physically extract the GID key.'"([https://firstlook.org/theintercept/document/2015/03/10/differential-power-analysis-apple-a4-processor/ The first document] and [https://firstlook.org/theintercept/document/2015/03/10/secure-key-extraction-physical-de-processing-apples-a4-processor/ the second one].)</blockquote>
  +
<blockquote>"According to the 2011 document describing the Jamboree presentations on Apple's processor, the researchers asserted that extracting the GID key could also allow them to look for other potential gateways into Apple devices. 'If successful, it would enable decryption and analysis of the boot firmware for vulnerabilities, and development of associated exploits across the entire A4-based product-line, which includes the iPhone 4, the iPod touch and the iPad.'"</blockquote>
  +
  +
The 2011 timing is interesting, since [[User:geohot|geohot]] had publicly released a powerful [[bootrom]] exploit ([[limera1n]]) for A4 devices in {{date|2010|10}}, which presumably the CIA was already using (probably one of the "very small number of security flaws, many of which are public, which Apple eventually patches" they mentioned). If a person has a bootrom exploit like limera1n, they can decrypt firmwares by generating the firmware keys from the [[KBAG]]s (since they can use the GID keys on-device even if they can't extract them) - see [[Firmware Keys]]. It's possible this talk had been written earlier and presented as still relevant for A5 and future chips.
  +
  +
=== Discussion of CIA research ===
  +
  +
[[User:NerveGas|NerveGas]] wrote [http://www.zdziarski.com/blog/?p=5009 a blog post about the implications of that article]. He says: "The UID key is what you’d want to get if you made an arrest and were looking to scrape data off of a suspect’s device. Instead, what CIA was trying to get instead was the GID, which is a key shared across an entire chip architecture (e.g. product line), that’s used for decrypting the low level boot firmware on a device...What that tells us is that CIA was NOT interested in getting forensic level access to personal data on a seized device in physical custody, but is instead more interested in cooking their own low level boot firmware to potentially deploy across an entire product line of device. With a private cache of exploits and/or cooked boot loader firmware, CIA could potentially infect millions of devices with malicious firmware to give them persistent access to monitor or surveil devices worldwide."
  +
  +
[[i0n1c]] wrote some tweets responding to the article and disputing what NerveGas said, including these (quoted in chronological order):
  +
* [https://twitter.com/i0n1c/status/575202998554595328 "The GID key allows you to decrypt iDevice firmware files. It does not allow you to pretend to be Apple. For that you need to break RSA."] (For context, RSA signatures are used in the [[SHSH]] system, which is Apple's [[wikipedia:digital signature|digital signature]] system designed to make sure only official Apple software can be installed on iOS devices.)
  +
* [https://twitter.com/i0n1c/status/575228562535550977 "The next thing is: I do not read in the abstracts linked by The Intercept that they actually succeeded in getting the GID key."]
  +
* [https://twitter.com/i0n1c/status/575228886985895936 "The abstract linked by The Intercept merely say that they are working on extracting the GID key and that it is work in progress."]
  +
* [https://twitter.com/i0n1c/status/575229014907953152 "Several Jailbreakers also tried hardware attacks to extract GID keys. Everybody with the capability did. So no surprise…"]
  +
* [https://twitter.com/i0n1c/status/575343599031820290 "The GID key does not enable you to prepare a fake firmware. For that you need first and foremost a digital signature."]
  +
* [https://twitter.com/i0n1c/status/575344476534751232 "The reason why the CIA and everybody else is after the GID key is simply because it allows decrypting firmware for reversing purposes."]
  +
* [https://twitter.com/i0n1c/status/575346239522357248 "BTW a single key for a single firmware file for a group is enough to create correctly encrypted (but not signed) firmware (no GID needed)"]
  +
* [https://twitter.com/i0n1c/status/575347464934420480 "With limera1n millions of people had access to the GID key via bootrom code. Not a single person managed to create a bad accepted firmware"]
  +
  +
The overall ''Intercept'' article was somewhat controversial among security researchers, with comments in [https://twitter.com/jeremyscahill/status/575509558556237825 this Twitter thread] and [http://blog.erratasec.com/2015/03/no-cia-isnt-stealing-apples-secrets.html this post] with [https://twitter.com/i0n1c/status/575550172815618049 responses], with disagreements about the goals of the CIA research and about which people should have been consulted as experts on the subject.
  +
  +
== Related tools ==
  +
* [http://iphonedevwiki.net/index.php/IOCryptoAcceleratorFamily IOCryptoAcceleratorFamily] - "a collection of kernel extensions that provide hardware-accelerated cryptographic functions, e.g. SHA1, AES, pseudo-random number generator (PRNG), etc."
  +
* [https://github.com/planetbeing/xpwn/tree/master/crypto crypto by planetbeing] - "This package allows you to directly access the iPhone's AES engine from userland. You may encrypt and decrypt with the UID and GID keys, as well as any custom keys you provide."
  +
* [https://code.google.com/p/iphone-dataprotection/ iphone-dataprotection] - wiki includes a list of [https://code.google.com/p/iphone-dataprotection/wiki/EncryptionKeys types of encryption keys used for data protection], including a chart of key hierarchy on iPhone 4.
  +
  +
[[Category:Decryption]]
  +
[[Category:Malware research]]

Latest revision as of 12:50, 17 September 2021

The GID key (Group ID key) is a 256-bit AES key shared by all devices with the same application processor. The GID key is part of how iOS encrypts software on the device (more explanation). This is one component of the iOS security system, which also includes SHSH signatures.

This key is different on each processor model (system on a chip) - in other words, the S5L8900 (chip for iPhone 3G for example) has a different key compared to the S5L8930 (A4 chip for iPhone 4, iPod touch (4th generation), etc.). On S5L8960 and later processors, the Secure Enclave has it's own GID that is separate from the AP's which is used to encrypt the SEP Firmware before delivery to the end user.

Apple explains GID keys in its official iOS security guide (page 9, chapter "Encryption and Data Protection"), along with UID keys:

"The device’s unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused (UID) or compiled (GID) into the application processor during manufacturing. No software or firmware can read them directly; they can see only the results of encryption or decryption operations performed using them. The UID is unique to each device and is not recorded by Apple or any of its suppliers. The GID is common to all processors in a class of devices (for example, all devices using the Apple A8 processor), and is used as an additional level of protection when delivering system software during installation and restore. Integrating these keys into the silicon helps prevent them from being tampered with or bypassed, or accessed outside the AES engine. The UID and GID are also not available via JTAG or other debugging interfaces."

On S5L8900, the GID key was used to generate AES Key 0x837, used as the encryption key for IMG2 files. With the introduction of IMG3 in iOS 2.0, iOS started using KBAGs instead of the 0x837 key. iOS 7.0 introduced the IM4P File Format and IMG4 File Format for A7 and newer devices.

In iOS 3.0GM/3.0, a pseudo GID Key was used, which allowed getting firmware decryption keys for these firmwares without the device and with tools such as GitKeys or OpenSSL. See Decrypting Firmwares#S5L8900.

Potential attacks

A hypothetical way to extract this key could be to perform some sort of side-channel attack (see also Talk:GID Key for more speculation about potential attacks).

A presentation from May/June 2011 that explains a variety of attacks aiming to get this kind of information out of a chip: Fault attacks on secure chips: from glitch to flash (Part 1) and Side-channel attacks: new directions and horizons (Part 2).

Research into AES key extraction using side-channel analysis, done from 2010 to 2012: developing new technology for efficient side-channel analysis - using a tool from Quo Vadis Labs.

CIA research into attacks

According to this March 2015 article in The Intercept based on documents provided by Edward Snowden, the CIA has been particularly interested in figuring out how to extract GID keys as part of their efforts to get access to modifying iOS to insert spy software and to research further vulnerabilities:

"At the 2011 Jamboree conference, there were two separate presentations on hacking the GID key on Apple’s processors. One was focused on non-invasively obtaining it by studying the electromagnetic emissions of — and the amount of power used by — the iPhone’s processor while encryption is being performed. Careful analysis of that information could be used to extract the encryption key. Such a tactic is known as a "side channel" attack. The second focused on a "method to physically extract the GID key.'"(The first document and the second one.)

"According to the 2011 document describing the Jamboree presentations on Apple's processor, the researchers asserted that extracting the GID key could also allow them to look for other potential gateways into Apple devices. 'If successful, it would enable decryption and analysis of the boot firmware for vulnerabilities, and development of associated exploits across the entire A4-based product-line, which includes the iPhone 4, the iPod touch and the iPad.'"

The 2011 timing is interesting, since geohot had publicly released a powerful bootrom exploit (limera1n) for A4 devices in October 2010, which presumably the CIA was already using (probably one of the "very small number of security flaws, many of which are public, which Apple eventually patches" they mentioned). If a person has a bootrom exploit like limera1n, they can decrypt firmwares by generating the firmware keys from the KBAGs (since they can use the GID keys on-device even if they can't extract them) - see Firmware Keys. It's possible this talk had been written earlier and presented as still relevant for A5 and future chips.

Discussion of CIA research

NerveGas wrote a blog post about the implications of that article. He says: "The UID key is what you’d want to get if you made an arrest and were looking to scrape data off of a suspect’s device. Instead, what CIA was trying to get instead was the GID, which is a key shared across an entire chip architecture (e.g. product line), that’s used for decrypting the low level boot firmware on a device...What that tells us is that CIA was NOT interested in getting forensic level access to personal data on a seized device in physical custody, but is instead more interested in cooking their own low level boot firmware to potentially deploy across an entire product line of device. With a private cache of exploits and/or cooked boot loader firmware, CIA could potentially infect millions of devices with malicious firmware to give them persistent access to monitor or surveil devices worldwide."

i0n1c wrote some tweets responding to the article and disputing what NerveGas said, including these (quoted in chronological order):

The overall Intercept article was somewhat controversial among security researchers, with comments in this Twitter thread and this post with responses, with disagreements about the goals of the CIA research and about which people should have been consulted as experts on the subject.

Related tools