Anti Cloning Technology on the GoPro HEROBus™ 2.0

FOR SECURITY RESEARCH / Interoperability with our products.  

Starting with the GoPro HERO5, the USB-C interface supports accessories such as a quick charger, a Mic adapter, and the Karma Drone/Grip. Briefly GoPro Inc. provided a developer program for access to this interface, but they soon dissolved that division as the company went south. 

After some, (a lot), of research, we've found the developer program only allowed access to a subset of the Herobus™ 2.0 (HB) functionality. Although I haven't bought a third party device, I assume they all fell under the "generic bacpac" identifier. We inferred it worked over i2c  and ran a protocol internally called GCCB. These devices worked on GoPro HERO5. That interface was never finished on the HERO[6,7] so it killed all those companies who signed up for the developer program. We had the foresight not to sign up for this program, so we have free reign to implement accessories without breaking a NDA.  

With that said, GCCB and an http tunnel, still works over USB -> via a PTP interface on the HERO6/7.  This allows the GoPro Karma and Karma Grip to operate on the newer cameras. 

Our HERO5 Interfaces blog post goes into these interfaces more but this article is about what prevents anyone from making an accessory for the GoPro. 

The Security Enclave (MCU)

Those who are new to the architecture of the GoPro HERO5 and greater, may not know that there is an encrypted security enclave (MCU) that provides some low-level functionality to the system. This is delved into more in this MCU blog post, but this enclave performs the following:

• Interfaces to a user attached USB-C device. Communicates to the Power Delivery Controller (PD) to determine power availability (voltage/current). 
• Communicates to the USB-C PD controller to determine the accessory attached.
• Securely houses keys for
• Secure updates of the MCU Bootloader
• Secure updates of the MCU Application 
• ATSHA204 Key
• Fuel Gauge Key
• Orchestrates signals to the USB-C device including I2S for the microphone, i2c for the security chip, VCONN power for unpowered devices, and HDMI for the HERO5 Session (internal).
• Securely performs SHA2 hashing of key pair to ensure accessory is original. 

Atmel ATSHA204A Anti-Cloning Protection

In order to prevent people like us to create awesome accessories for their products, GoPro added anti-cloning technology. They do this by populating a ATSHA204a on any accessory preprogrammed with a preshared key. We assume developer program members were allowed to purchase these pre-programmed “keys” and installed one on each of there products. I wouldn’t be surprised if the cost was inflated and acted as a royalty for each unit sold. 

How it works

The MCU creates a challenge, sends it to the Atmel ATSHA204A and then reads the resulting hash. Internally, the MCU calculates the hash and see's if these hashes compare. Since the MCU and the ATSHA204a are encrypted, and the latter is hardened, it is very difficult to determine the key. Brute force is impossible with the current technology so some sort of side channel is required. 

Cryptography on ATSHA204 

The Secret Key is only known to the ATSHA204a and can be thought of as a private key. 

The NONCE & the resulting pre-calculated TmpKey is known to the MCU security enclave. This is securely stored within the MCU, and can be different between hardware classes. 

The Challenge is pseudo random and whose entropy is based upon tick counts. 

The Digest is the result of the TmpKey & Challenge.

Cryptography on MCU

The MCU has a copy of the resulting TmpKey for the passed NONCE. It uses ONLY the TmpKey and previously sent challenge to internally calculate the resulting Digest.

In the end, the resulting digest is compared to the response of the ATSHA204 computation and authentication is validated. 

Challenge

The challenge is the MCU's serial number with DWORD[3] merged with a tick count. Because of this, replay attacks are trivial if the device is always plugged in on power on. 

Key

The Key is held in slot 1. It is 32 bits long and not text based. 

MAC_command Static Data

The parts sourced from ATMEL to GoPro have an unique Serial Number 8 key. In the specification they are said to return 0xEE. On these devices they return 0xC6.

So you don't have to scour the datasheet

memset suffix to 24 0's 

suffix[0] = 8; // command
suffix[1] = 6; // mode
suffix[2] = 0; // Slot id 0
suffix[3] = 0;
// serial number // GoPro's unit has 0xC6 vs 0xEE identifier
suffix[15] = 0xC6; // sn8
suffix[20] = 0x01; // note sn0 is first 
suffix[21] = 0x23; // sn1

Exploits

The key stored within the ATSHA204 acts as a the master key. The Nonce/TmpKey pairs known to the MCU can be thought of as subordinate keys. 

Even if a MCU for a particular GoPro camera model is compromised, the NONCE / TmpKey pair can be changed between revisions of cameras. This makes knowing the NONCE / TmpKey pair not as useful as one would expect. Until the ATSHA204 key is determined, each new interfacing hardware could have a distinct NONCE / TmpKey pair. We have yet to explore how many distinct pairs exists. 

More Information

<Our previous article on this, slightly updated>

The ATSHA204A contains an encrypted 256bit key called data.SLOT1. The configured ATSHA204A contains 11 other 'issecret' slots which can be moved to in case one gets compromised.

The steps the gopro does: 

1. Loads a "NONCE". 
2. Generate a digest GenDig with the SHA256(data.SLOT1[32] + staticdata + NONCE[32])
3. Create a MAC from the SHA256(GenDig[32] + MCU-ID[32]  + staticdata).   
4. Compare digest in MCU's encrypted memory 

ATSHA204 transaction details

1. ATSHA204 NONCE ::  Command: 0x16, Param1: 3, Param2: 0  
2. ATSHA204 GENDIG :: Command: 0x15, Param1: 2, Param2: 1  
3. ATSHA204 MAC       :: Command: 0x08, Param1: 6 Param2: 0 

Psuedo Code (MCU v1.50)

NONCE = fixed-challenge

 // GenDig: message = data.SLOT1 + OpCode + Param1 + Param2 + SN[8] + SN[0:1] + padding: x 25 + NONCE

 message = data.SLOT1 + 0x15 + 0x02 + 0x01 + 0xC6 + 0x1 + 0x23 + {'0x0'*25} + NONCE 

 DIGEST = SHA256(message)

 //  MAC: full_challenge = SLOT:0 + challenge + opcode + mode + param1+ param2 + zeros x 8 + zeros x 3 + SN[8] + zeros x 4 + SN[0:1] + zeros x 2

 full_challenge[] = GenDig[32] + MCU-ID[32] + 08h + 06h + 00h + 00h + {'0x00'*8} + {'0x00'*3} + 0xC6 + {'0x00'*4} + {'0x01,0x23} + {'0x00'*2} (Had it improperly as digest vs. key earlier)

 RESULT = SHA256(full_challenge)

 Notes: Entropy comes from MCU-ID which has 3 bytes of randomness per boot. Replay attack is possible per camera with 4GB of data. 

Tests

Output of the MAC on the below test sequence. 

Challenge once NONCE is loaded
0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77,
0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF,
0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77,
0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF

Response

(Actual)
0xcd, 0x93, 0x1a, 0x98, 0xcd, 0x20, 0x96, 0x14,
0x3e, 0x0d, 0xd5, 0x02, 0x22, 0xc3, 0x4e, 0x47, 
0x21, 0x81, 0x21, 0xe9, 0x10, 0xf2, 0x95, 0x46,
0x8e, 0x59, 0x3b, 0x4a, 0x7c, 0x0b, 0xa7, 0xdc 

Pure MAC with Key0? 
0xC4, 0x64, 0xf3, 0x9c, 0x43, 0x02, 0x7c, 0xde, 
0x19, 0x76, 0x35, 0x61, 0x71, 0xed, 0xc3, 0xc6, 
0x37, 0x4a, 0x17, 0x9b, 0xDA, 0x70, 0x1a, 0x07, 
0xcd, 0xa1, 0x8f, 0xe1, 0x2d, 0xa5, 0x47, 0xf2, 

   0xc0, 0x2e <-- CRC

Scan

For those looking to explore here is the output from a read of our ATSHA204A

wakeup passed
Dev Rev via cmd: 00 09 60 00

Serial number: 01 23 XX XX XX XX XX XX C6 <- Not EE like spec
Revision number: 00 09 04 00
I2C enabled; Address: 0xC4
OTP mode: consumption
Selector: can be updated only if it is 0.
User Extra byte: 00
Selector byte: 00

Data and OTP zones are locked!

Config zone is locked!

Configurations of slots:

Slot:0 ReadKey:F CheckOnly:0 SingleUse:0 EncryptRead:0 IsSecret:1
  WriteKey:F WriteConfig:8
  UseFlag:FF UpdateCount:00

Slot:1 ReadKey:F CheckOnly:0 SingleUse:0 EncryptRead:0 IsSecret:1
  WriteKey:F WriteConfig:8
  UseFlag:FF UpdateCount:00

Slot:2 ReadKey:F CheckOnly:0 SingleUse:0 EncryptRead:0 IsSecret:1
  WriteKey:F WriteConfig:8
  UseFlag:FF UpdateCount:00

Slot:3 ReadKey:F CheckOnly:0 SingleUse:0 EncryptRead:0 IsSecret:1
  WriteKey:F WriteConfig:8
  UseFlag:FF UpdateCount:00

Slot:4 ReadKey:F CheckOnly:1 SingleUse:1 EncryptRead:0 IsSecret:1
  WriteKey:F WriteConfig:8
  UseFlag:FF UpdateCount:00

Slot:5 ReadKey:F CheckOnly:1 SingleUse:0 EncryptRead:0 IsSecret:1
  WriteKey:F WriteConfig:8
  UseFlag:FF UpdateCount:00

Slot:6 ReadKey:F CheckOnly:1 SingleUse:0 EncryptRead:0 IsSecret:1
  WriteKey:F WriteConfig:8
  UseFlag:FF UpdateCount:00

Slot:7 ReadKey:F CheckOnly:1 SingleUse:0 EncryptRead:0 IsSecret:1
  WriteKey:F WriteConfig:8
  UseFlag:FF UpdateCount:00

Slot:8 ReadKey:F CheckOnly:0 SingleUse:0 EncryptRead:0 IsSecret:0
  WriteKey:F WriteConfig:8
  00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00

Slot:9 ReadKey:F CheckOnly:0 SingleUse:0 EncryptRead:0 IsSecret:0
  WriteKey:4 WriteConfig:C
  00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00

Slot:A ReadKey:F CheckOnly:0 SingleUse:0 EncryptRead:0 IsSecret:0
WriteKey:5 WriteConfig:C
  00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00

Slot:B ReadKey:F CheckOnly:0 SingleUse:0 EncryptRead:0 IsSecret:0
WriteKey:F WriteConfig:0
  00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00

Slot:C ReadKey:F CheckOnly:0 SingleUse:0 EncryptRead:0 IsSecret:1
  WriteKey:F WriteConfig:8

Slot:D ReadKey:F CheckOnly:0 SingleUse:0 EncryptRead:0 IsSecret:1
  WriteKey:D WriteConfig:2

Slot:E ReadKey:F CheckOnly:0 SingleUse:0 EncryptRead:0 IsSecret:1
  WriteKey:6 WriteConfig:C

Slot:F ReadKey:F CheckOnly:0 SingleUse:0 EncryptRead:0 IsSecret:1
  WriteKey:F WriteConfig:8

LastKeyUse: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF