Skip to content
  • About Me
  • Books
  • Photography
  • Papers
  • Security
  • Forensics
  • Essays
  • Christianity

Calendar

July 2022
M T W T F S S
 123
45678910
11121314151617
18192021222324
25262728293031
« Jun    

Archives

  • June 2022
  • May 2022
  • March 2022
  • January 2022
  • December 2021
  • November 2021
  • September 2021
  • July 2021
  • January 2021
  • December 2020
  • November 2020
  • March 2020
  • September 2019
  • August 2019
  • November 2018
  • August 2018
  • March 2018
  • March 2017
  • February 2017
  • January 2017
  • November 2016
  • October 2016
  • July 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • June 2015
  • March 2015
  • February 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • January 2014
  • October 2013
  • September 2013
  • June 2013
  • May 2013
  • April 2013
  • December 2012
  • May 2012
  • September 2011
  • June 2011
  • August 2010
  • July 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • July 2009
  • May 2008
  • March 2008
  • January 2008
  • June 2007
  • August 2006
  • February 2006

Categories

  • Apple
  • Christianity
  • Essays
  • Forensics
  • General
  • Machine Learning
  • Music
  • Opinion
  • Photography
  • Politics
  • Security











ZdziarskiDFIR, security, reverse engineering, photography, theology, funky bass guitar. All opinions are my own.
  • About Me
  • Books
  • Photography
  • Papers
  • Security
  • Forensics
  • Essays
  • Christianity
Apple . Forensics . Security

Hardware-Entangled APIs and Sessions in iOS

On April 26, 2016 by Jonathan Zdziarski

Apple has long enjoyed a security architecture whose security, in part, rests on the entanglement of their encryption to a device’s physical hardware. This pairing has demonstrated to be highly effective at thwarting a number of different types of attacks, allowing for mobile payments processing, secure encryption, and a host of other secure services running on an iPhone. One security feature that iOS lacks for third party developers is the ability to validate the hardware a user is on, preventing third party applications from taking advantage of such a great mechanism. APIs can be easily spoofed, as a result, and sessions and services are often susceptible to a number of different forms of abuse. Hardware validation can be particularly important when dealing with crowd-sourced data and APIs, as was the case a couple years ago when a group of students hacked Waze’s traffic intelligence. These types of Sybil attacks allow for thousands of phantom users to be created off of one single instance of an application, or even spoof an API altogether without a connection to the hardware. Other types of MiTM attacks are also a threat to applications running under iOS, for example by stealing session keys or OAuth tokens to access a user’s account from a different device or API. What can Apple do to thwart these types of attacks? Hardware entanglement through the Secure Enclave.

The Secure Enclave (SEP) performs a number of functions at the core of hardware entanglement, such as the passcode entanglement function used by Apple’s encryption scheme. The SEP has direct hooks into the encryption routines embedded on silicon, and prevents a number of cryptanalytic attacks by binding the encryption to the hardware. It also has its own encrypted storage. The SEP could be used to perform digital signing on behalf of applications in a similar fashion, and this digital signing can help to authenticate a third party session. So how could this work?

Here’s one example: A public / private key pair identity could be generated on devices and embedded in the SEP. This key pair would be signed by an Apple key and would represent a device’s identity (it, too, could be entangled with the device’s UID to protect the private key). When establishing a new session, this device’s public key is sent to the server (for example, Waze’s servers). The public key’s signature is verified with an Apple public key, which authenticates the device as a genuine Apple device. A challenge including a session key, a nonce, and a timestamp, is encrypted using the device’s public key and then sent to the device using whatever transport encryption on top of that. The third party application uses an API to pass the encrypted challenge to the Secure Enclave, which decrypts it and returns the decrypted content back to the application. The application then uses the session key to establish a session with the server, signs the challenge containing the nonce and timestamp, and returns it back to the server. The server verifies the signature and the session can commence. Additional challenges can be made at any time, however the initial session’s key can be trusted because only the Secure Enclave on the owner’s device could decrypt it (and authenticate the challenge).

Apple does already have the infrastructure to do something like this within the SEP, and it’s used to better protect Touch ID authentication and to manage enrollments for third party apps; it is not, however, signed by Apple, and so there doesn’t appear to be any way to authenticate the hardware, which is at the core of how a Sybil attack could be thwarted.

If Apple were concerned about device tracking, they could further abstract this by generating new key pairs when advertising ids are reset, for example, although the chain of trust would have to be tweaked to accommodate this.

There are certainly a number of other, similar dances that Apple could use to establish hardware-entangled sessions. The idea here is to use the Secure Enclave for digital signing as well as for PKI when establishing a new session, and authenticating the PKI using an Apple cert to sign device identities. This would effectively tie a remote session to a device, allowing the server to be more resilient against Sybil attacks and certain forms of MiTM attacks.

Apple would be the only ones that could effectively implement this into their hardware architecture. The result, however, would be very beneficial to Apple in that it would create a more trusted platform for third party developers to build on, more robust remote sessions, and an overall more secure experience for the user.

Archives

  • June 2022
  • May 2022
  • March 2022
  • January 2022
  • December 2021
  • November 2021
  • September 2021
  • July 2021
  • January 2021
  • December 2020
  • November 2020
  • March 2020
  • September 2019
  • August 2019
  • November 2018
  • August 2018
  • March 2018
  • March 2017
  • February 2017
  • January 2017
  • November 2016
  • October 2016
  • July 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • June 2015
  • March 2015
  • February 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • January 2014
  • October 2013
  • September 2013
  • June 2013
  • May 2013
  • April 2013
  • December 2012
  • May 2012
  • September 2011
  • June 2011
  • August 2010
  • July 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • July 2009
  • May 2008
  • March 2008
  • January 2008
  • June 2007
  • August 2006
  • February 2006

Calendar

July 2022
M T W T F S S
 123
45678910
11121314151617
18192021222324
25262728293031
« Jun    

Categories

  • Apple
  • Christianity
  • Essays
  • Forensics
  • General
  • Machine Learning
  • Music
  • Opinion
  • Photography
  • Politics
  • Security

All Content Copyright (c) 2000-2022 by Jonathan Zdziarski, All Rights Reserved