At a high level, SmartGlass uses:

Key Exchange

In detail, key exchange works like this:

  1. On Discovery, the console responds with a Discovery Response including a certificate, this certificate holds the console’s public key.
  2. The client generates elliptic curve and derives the shared secret with console’s public key using ECDH and a randomly generated public/private keypair
  3. The shared secret is salted using static salts, see KDF Salts
  4. The salted shared secret is hashed using SHA-512
  5. The salted & hashed shared secret is split into the following individual keys:
    • bytes 0-16: Encryption key (AES-128-CBC)
    • bytes 16-32: Initialization Vector key (AES-128-CBC)
    • bytes 32-64: Hashing key (HMAC-SHA-256)
  6. The client’s public key is sent inside the Connect Request message to the console

KDF Salts

IV Generation

Connect Request

The IV is randomly generated and transmitted inside the unprotected payload section of the Connect Request packet.


The IV is generated by encrypting the first 16 bytes of the packet header with AES-CBC-128 and a null IV.

Protected Payload Length

The protected payload length inside the header indicates the data length without padding.


Protected payloads are padded using out of specification PKCS#7 algorithm to match needed aligment for encryption.

How it differs from specification: Plaintext needs to be aligned to 16 bytes. If the plaintext is 16 bytes aligned already, NO PADDING is used.

NOTE: By specification, a whole padding block (16 bytes) would be appended to the plaintext.


Plaintext (12 bytes) DE AD BE EF DE AD BE EF DE AD BE EF

Padded (12+4 bytes) DE AD BE EF DE AD BE EF DE AD BE EF 04 04 04 04

As you can see, the padding consists of the count of bytes:

2 byte padding: 02 02

3 byte padding: 03 03 03

6 byte padding: 06 06 06 06 06 06

Message Authentication

All encrypted packets are authenticated using HMAC-SHA-256. The produced hash has a length of 32 bytes (0x20).

Auxiliary Stream encryption

Cryptography parameters for Title channel aka. Auxiliary Stream are transmitted via Auxiliary Stream message.

The host sets all the crypto parameters and informs the client about it. Client then uses received AES key, HMAC key and Client/Server IV to setup the crypto context.