Mobile Authenticator Specification

From AddOn Studio
Jump to navigation Jump to search

Template:Source needed



Technical description of the Mobile Authenticator protocol:

Server Communication[edit]

Authenticator Initialization[edit]

Authenticator Initialization Request[edit]

Initialization request is an HTTP POST request to

  • (Europe) (old)
  • (North America) (old)
  • (new)

with Content-type "application/octet-stream".

The plaintext of the request has the following format:

function code response encryption key region code mobile model
1 byte 37 bytes 2 bytes 16 bytes
Function code
always 0x01
Response encryption key
Random bytes for one time pad encryption of the response. Blizzard is using the default Java random number generator (initialized with the current system time), hashes the created random bytes via SHA1 and is using the hash output for the key. But every other good source of randomness would be also OK here.
Region code
"EU" or "US" but doesn't have any meaning - distinction is only done via the URL and not via the code here.
Mobile model
Default value is "Motorola RAZR v3" but every other 16 bytes would be also OK. Seems to be only a statistical record.

The plaintext is then encrypted with RSA-1024 (upper bytes of the RSA-block are padded with zeros). The modulus is


(big endian) and the public exponent is "0x101" (257). The resulting 128 encrypted bytes are sent to the server within the HTTP-POST-request. Europe and North America are using the same keys for RSA.

Authenticator Initialization Response[edit]

The HTTP body of the response has the following format:

current server time encrypted initialization data
8 bytes 37 bytes
Current server time
Milliseconds since midnight, January 1, 1970 UTC (like returnded by System.currentTimeMillis() in Java), big endian format.
Encrypted initialization data
One time pad encrypted data with initialization information for the authenticator. The decryption key is the key sent to the server within the initialization request.

After decryption the initialization information has the following format:

secret key for code calculation authenticator serial number
20 bytes 17 bytes
Secret key for code calculation
Secret key generated by the server for calculation of the authenticator codes. Refer to code calculation section for the usage of this key. The key MUST be stored within the authenticator as long as it is linked to a account and MUST kept secret.
Authenticator serial number
Serial number of the authenticator used for linking it to a account. It has the format "EU-1234-5678-9012" or "US-1234-5678-9012". The number seems to be simply incremented by the server for every initialization request. There should be no way to calculate the secret key corresponding to this serial number. The serial number SHOULD be stored together with the secret key. Though it isn't any longer possible to link a single authenticator to more than one account at a time[1], but maybe the support will ask for the serial number if there is a problem with the authenticator.

Authenticator Time Synchronization[edit]

Authenticator Time Synchronization Request[edit]

Synchronization request is simply an HTTP GET request to

  • (Europe) (old)
  • (North America) (old)
  • (new)

Authenticator Time Synchronization Response[edit]

The HTTP body of the response has the following format:

current server time
8 bytes
Current server time
Milliseconds since midnight, January 1, 1970 UTC (like returned by System.currentTimeMillis() in Java), big endian format.

Code Calculation[edit]

Starting point of the calculation are the secret key (returned by the server within the authenticator initialization response) and the current code interval number. Code interval length is 30 seconds (every 30 seconds a new code is generated). To calculate the current code interval number the current server time in milliseconds (as returned from the time synchronization request) has to be known and is simply divided by 30,000 (midnight, January 1, 1970 UTC started with code interval 0 and every 30 seconds the code interval counter is incremented by 1).

If there is a local clock with enough accuracy available, it is not necessary to request the server time for every code calculation. It is enough to store the time difference between server and local clock when doing the initialization of the authenticator and calculate the current server time from the local time and the stored time difference. Only if the divergence between server and local clock has significantly changed, a new synchronization has to be done.

The code interval number is stored in 8 bytes (big endian order) and is used as message for HMAC-SHA1 (the key is the secret key from the initialization response). The result is a 20 bytes MAC of the code interval number. From this 20 bytes MAC 4 bytes are selected as the current code. The last 4 bit of the MAC determine the starting byte of the 4 selected bytes.

Finally the last 8 digits (radix 10) of the 4 selected bytes (big endian order) are displayed by the authenticator as the current code.

Short form:

// calculate current interval number

// calculate HMAC-SHA1 from secret key and interval number
byte[20] mac = HMAC-SHA1(SECRET_KEY, intervalNumber)

// determine which 4 bytes of the MAC are taken as the current code
// last 4 bit of the MAC points to the starting byte
int startPos = mac[19] & 0x0F

// select the byte at starting position and the following 3 bytes
int selectedInt = mac[startPos .. startPos + 3]

// use the lowest 8 decimal digits from the selected integer as the
// current authenticator code
return selectedInt % 100000000


  1. Blizzard Entertainment: Blog: Authenticator Change (Oct 7, 2010)


External links[edit]