bcm-v4

[Specification

Overview

The chipset includes a hardware crypto engine that is fairly powerful. For some reason, Broadcom decided to disable TKIP hardware acceleration in later drivers, so we don't really know if/how that would work.

The key material is located at the SHM offset pointed to by the value of the Key table pointer SHM register multiplied by two (byte offset, the register gives word offset which apparently ucode uses internally). Each key is up to 16 bytes long, core revision >= 5 supports up to 58 entries and others up to 20 entries.

The key material is organized differently depending on microcode revision. The unlisted revisions should use one of the layouts but we don't know which one.

revision <= 323

table index (index in key material array)

0 - 3

4 - 7

8 and higher

key index (in TX header and algo block)

0 - 3 (TX)

0 - 3 (RX)

4 and higher (TX/RX)

contents

default TX keys

default RX keys

per-station keys used with address match (MAC addresses 0 - N-1)

revision >= 351

table index (index in key material array)

0 - 3

4 and higher

key index (in TX header and algo block)

0 - 3

4 and higher (TX/RX)

contents

default TX/RX keys

per-station keys used with address match (MAC addresses 0 - N-1)

The hardware probably uses the "Key Index/Algo Block" in the SHM to figure out which key from the key material SHM is used for a given key number, but it is only ever set to an identity mapping.

Crypto Acceleration During Transmission

During transmission, the key index and algorithm are set in the Mac TX Control High part of the transmit header.

Reception

Decryption during reception depends on either default keys (in the case of WEP and groupwise keys) or address matching. This is fairly hairy, especially due to differences between core revisions.

First, let's get some basics. When encrypted unicast frames are received, the hardware will first attempt to find the key matching the transmitter address (see below). If none is found, it uses the key index field if (and only if!) the "enable use of default keys" host flag is set. For multi- and broadcast frames, the key index is used always, regardless of the flag. For WPA, configurations using only group keys are unsupported, hence this flag should only ever be set for WEP.

While changing a key, you should zero the corresponding mac address so the hardware doesn't try using that invalid key.

Address matching (RCMTA mechanism)

Newer core revisions (>= 5) support the RCMTA (receive match transmitter address) mechanism for this purpose.

The RCMTA memory contains up to 50 MAC addresses. These are matched on unicast frame reception, and if one matches then the index of the matching address + 4 (since there are 4 default keys) is the key index of the key used to decrypt the frame. Note that the RCMTA memory is indexed by 32-bit words and each MAC address occupies one and a half words with the upper 4 bytes of the mac address occupying the first word and the lower 2 bytes in the second word. It is easiest to add a mac address with one 32-bit write to 2*idx and a 16-bit write to 2*idx+1.

Address matching (RXE/PSM mechanisms)

Older core revisions (< 5) support only the RXE (receive engine) with up to 4 key addresses and the PSM engine with up to 8 key addresses.

The RXE engine matches use keys 4 through 7 (0 through 3 are the default keys), the PSM (programmable state machine) matches use keys 8 through 15. Addresses to match with the RXE engine are written to RCM offsets 16, 19, 22 and 25 respectively, addresses to match with the PSM are simply written into the SHM "PSM transmitter address match block".

crypto algorithms

number

algorithm

0

none (no crypto done but "decrypt attempted" may be set on RX)

1

WEP 1 (40 bit WEP)

2

TKIP

3

AES

4

WEP 128

5

AES legacy


Exported/Archived from the wiki to HTML on 2016-10-27