|
|
| Line 1: |
Line 1: |
| {{source needed}} | | {{wowapitype}} |
| Technical description of the [[Battle.net Mobile Authenticator]] protocol:
| |
|
| |
|
| ==Server Communication==
| | A common set of parameters for determining a special Group type. Added in 5.0.4. |
|
| |
|
| ===Authenticator Initialization=== | | == Values == |
| | * LE_PARTY_CATEGORY_HOME - the local or manually created group. |
| | * LE_PARTY_CATEGORY_INSTANCE - the player's automatic battleground, arena, or dungeon finder group. |
|
| |
|
| ====Authenticator Initialization Request==== | | == Uses == |
| Initialization request is an HTTP POST request to
| | : groupType - (optional) the type of group. Default is 'LE_PARTY_CATEGORY_INSTANCE' if in an instance group, otherwise 'LE_PARTY_CATEGORY_HOME'. |
| :* ''<nowiki>http://m.eu.mobileservice.blizzard.com/enrollment/enroll.htm</nowiki>'' (Europe) | |
| :* ''<nowiki>http://m.us.mobileservice.blizzard.com/enrollment/enroll.htm</nowiki>'' (North America)
| |
| with Content-type "application/octet-stream".
| |
|
| |
|
| | == Details == |
| | The purpose is to differentiate when a player is a member of more than one group, which group is meant. A player can be in a locally created group or an automatic group (ala Finder). |
|
| |
|
| The plaintext of the request has the following format:
| | === Examples === |
| {|class="darktable"
| | /run local x=UnitIsGroupLeader("Player", LE_PARTY_CATEGORY_INSTANCE); SendChatMessage(tostring(x)) |
| |-
| | /run local x=UnitIsGroupLeader("Player", LE_PARTY_CATEGORY_HOME); SendChatMessage(tostring(x)) |
| !style="width:15%;" align="left"| function code
| | For example if you logged in, then joined a normal finder dungeon group and happend to be the leader, then using 'LE_PARTY_CATEGORY_INSTANCE' on UnitIsGroupLeader for yourself, will return 'true' and using 'LE_PARTY_CATEGORY_HOME' will return 'false'. This is because in your 'home world' or 'explicit group' you are not in a 'group' and you are no 'leader' there, but in the 'foriegn world' or 'automatic group' you are the 'leader'. |
| !style="width:40%;" align="left"| response encryption key
| |
| !style="width:15%;" align="left"| region code
| |
| !style="width:30%;" align="left"| 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.
| |
|
| |
|
| | == Changes == |
| | * [[Patch 5.0.4]] - added. |
|
| |
|
| The plaintext is then encrypted with RSA-1024 (upper bytes of the RSA-block are padded with zeros). The modulus is
| | == See also == |
| 0x955e4bd989f3917d2f15544a7e0504eb9d7bb66b6f8a2fe470e453c779200e5e
| | * {{api|GetNumGroupMembers}} |
| 3ad2e43a02d06c4adbd8d328f1a426b83658e88bfd949b2af4eaf30054673a14
| | * {{api|GetNumSubgroupMembers}} |
| 19a250fa4cc1278d12855b5b25818d162c6e6ee2ab4a350d401d78f6ddb99711
| | * {{api|UnitIsGroupLeader}} |
| e72626b48bd8b5b0b7f3acf9ea3c9e0005fee59e19136cdb7c83f2ab8b0a2a99
| | * {{api|UnitIsGroupAssistant}} |
| (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====
| |
| The HTTP body of the response has the following format:
| |
| {|class="darktable" | |
| |-
| |
| !style="width:40%;" align="left"| current server time
| |
| !style="width:60%;" align="left"| 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:
| |
| {|class="darktable"
| |
| |-
| |
| !style="width:60%;" align="left"| secret key for code calculation
| |
| !style="width:40%;" align="left"| 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|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 Battle.net account and ''MUST'' kept secret.
| |
| ;Authenticator serial number
| |
| : Serial number of the authenticator used for linking it to a Battle.net 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 Battle.net account at a time<ref>Blizzard Entertainment: Battle.net Blog: [http://us.battle.net/sc2/en/blog/882513 Battle.net Authenticator Change] (Oct 7, 2010)</ref>, but maybe the support will ask for the serial number if there is a problem with the authenticator.
| |
| | |
| | |
| ===Authenticator Time Synchronization===
| |
| | |
| ====Authenticator Time Synchronization Request====
| |
| Synchronization request is simply an HTTP GET request to
| |
| :* ''<nowiki>http://m.eu.mobileservice.blizzard.com/enrollment/time.htm</nowiki>'' (Europe)
| |
| :* ''<nowiki>http://m.us.mobileservice.blizzard.com/enrollment/time.htm</nowiki>'' (North America)
| |
| | |
| | |
| ====Authenticator Time Synchronization Response====
| |
| The HTTP body of the response has the following format:
| |
| {|class="darktable" | |
| |-
| |
| !align="left"| current server time
| |
| |-
| |
| | 8 bytes
| |
| |}
| |
| ;Current server time
| |
| : Milliseconds since midnight, January 1, 1970 UTC (like returnded by System.currentTimeMillis() in Java), big endian format.
| |
| | |
| | |
| ==Code Calculation==
| |
| 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
| |
| long intervalNumber = (CLIENT_TIME_IN_MILLISECONDS + TIME_DIFFERENCE_TO_SERVER) / 30000
| |
|
| |
| // 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
| |
| | |
| == References ==
| |
| {{reflist}}
| |
| | |
| == Sources ==
| |
| * {{Wowpedia credit|date=2 Feb 2011}} | |
| | |
| == External links ==
| |
| {{elink|site=Google.com|link=http://webcache.googleusercontent.com/search?q=cache:_jPFKes8ymMJ:bnetauth.freeportal.us/+bnetauth&cd=2&hl=en&ct=clnk&gl=us&client=firefox-a&source=www.google.com|desc=Web cache of defunct <tt>bnetauth.freeportal.us</tt>}} | |
| {{elink|site=github.com|link=https://github.com/Adys/python-bna|desc=Code for open source python implementation of authenticator}}
| |
| {{elink|site=github.com|link=https://github.com/krtek4/php-bma|desc=Code for open source PHP implementation of authenticator}} | |
| [[Category:World of Warcraft API]]
| |