How Application Authorization works on the Nintendo Switch
Hey, all.
After doing some research earlier today into how the Switch gains authorization to play a given game online, I learned that Nintendo has implemented some very strong anti-piracy measures in this regard -- they can actually
perfectly detect whether a digital copy of a game has been legitimately purchased. I figured I'd make a post explaining the process, since it's pretty technically interesting.
Overview
Here's what happens when you attempt to connect online in a game, in the abstract:
- Your console verifies that it can connect to the internet.
- Your console verifies that it can get a device authorization token to go online -- that it is not banned.
- Your console authorizes the Nintendo Account being signed into.
- Your console obtains an application authorization token for the specific title being played.
Hopefully at a high level, all that makes sense. Now, let's dive in to more technical detail:
Your console verifies that it can connect to the internet.
This step is pretty self-explanatory, but I'm including it for the sake of being thorough. Your console periodically connects to "ctest.cdn.nintendo.net", and checks the response for a special header -- "X-Organization: Nintendo". If that header is present, your console concludes it has access to the internet. Otherwise, it decides it doesn't -- it's really straightforward.
Let's get to the more interesting stuff.
Some background
For those that haven't read
my other Switch networking post, I recommend you go do so -- it's pretty interesting. There's only one really important bit to keep in mind for this, though, so I'll just repeat it here:
On the Switch, only bugyo is unauthenticated -- every other server authenticates requests, and will reject any requests lacking the right client certificates. In addition, client certificates are now console-unique, and burned in at the factory. Client certificate private key data is stored encrypted using keydata only available to
TrustZone (an isolated security-focused cpu core, which provides a cryptography API), and the
ssl module retrieves it on boot by interfacing with the settings service to retrieve the encrypted data and then requesting that the
spl module pass it to TrustZone for decryption via the "GenerateAesKek" and "DecryptPrivk" commands.
Note that unlike the 3DS, this means that Nintendo can tell what console makes a given request. This means Nintendo can block misbehaving user's certificates, leaving them permanently unable to use any of Nintendo's network.
Your console verifies that it can get a device authorization token to go online
This is one of the meatier bits of the online connection process. Nintendo has a special server for handing out device authorization tokens -- "dauth-lp1.ndas.srv.nintendo.net" (Device AUTHorization, and lp1 is the "live production" environment for retail online services). One thing that's important to note is that these tokens don't blanket-authorize all system operations -- they are handed out to specific parts of the system, specified by a
client id in the token request. With that out of the way, here's how device authorization works:
- Your console connects to the dauth "/challenge" endpoint, sending up a "key_generation" argument informing the server what master key revision your console is using.
- Dauth sends back as a json a random "challenge" string, and a constant "data" string.
- Your console treats the "data" string, decoded as base-64, as a cryptographic key source, and uses the SPL services to transform it with TrustZone only keydata and load it into an AES keyslot.
- Your console generates its authorization request data -- this is done by formatting the string "challenge=%s&client_id=%016x&key_generation=%d&system_version=%s" with the challenge string, the client ID requesting a token, the master key version, and the current system version digest.
- Your console calculates an AES-128 CMAC using the trustzone-only key it derived over its authorization request, appends "&mac=%s" to the request data (formatting with the url-safe base 64 encoded CMAC), and fires the request off to the "/device_auth_token" endpoint.
- If all goes well, dauth returns a token for your console. (If your console is banned, as one of mine is, you will instead receive an error message informing you that your console is not allowed to use online services).
This is a pretty effective custom scheme -- it requires, in order to get a token, that the requester be able to perform TrustZone-only cryptographic operations for the current system version. Provided TrustZone isn't compromised on the latest firmware, this is totally safe. TrustZone is, for better or worse, compromised on all system versions due to shofusel2, though. This means the only real benefit here is that dauth provides an ideal place for console bans to be implemented -- almost all interesting online functionality requires a dauth token of some kind, including purchasing and installing new games from the eShop, so consoles that get blocked here can't do much besides install system updates.
Your console authorizes the Nintendo Account being signed into.
This is actually somewhat uninteresting, too -- there is nothing Switch unique here. Your console performs pretty bog-standard oauth authorization talking to "api.accounts.nintendo.com" -- this is the same process performed on a PC, and so I won't go into it in detail here.
The only meaningful upshot to this component is that it allows Nintendo to block specific accounts, and because
all requests require a client certificate, any blocked account can be immediately associated to a console.
Your console obtains an application authorization token for the specific title being played.
This is the really interesting component -- and it's where Nintendo's strongest security measure lies.
Like dauth, Nintendo has a special server for this -- "aauth-lp1.ndas.srv.nintendo.net" (Application AUTHorization). Going online in a game requires getting a token from the "/application_auth_token" endpoint. Here's how that works, at a high level:
- Your console gets a device authorization token from dauth for the aauth client ID.
- Your console retrieves its certification to play the title it's trying to connect online with, and sends that to aauth.
- If all goes well, aauth returns an application authorization token.
Now, that's not too complicated. But what's really interesting is the bit where
your console retrieves its certification to play the title it's trying to connect online with.
Let me explain that in more technical detail for both cases:
Gamecards
- If you are playing a gamecard, your certification is your gamecard's unique certificate. This is signed by Nintendo using RSA-2048-PCKS#1 at the time your gamecard is written, and contains encrypted information about your gamecard (this includes what game is on the gamecard, among other, unknown details).
- In the gamecard case, the data uploaded to aauth is "application_id=%016llx&application_version=%08x&device_auth_token=%.*s&media_type=GAMECARD&cert=%.*s", formatted with the title ID for the game being played, the version of the game being played, the token retrieved from dauth, and the gamecard's certificate (retrieved from FS via the "GetGameCardDeviceCertificate" command), formatted as url-safe base64.
- This code lives at .text+0x7DE1C for 5.0.0 account.
Digital games
- Your certification for a digital title is your console's ticket. For more technical details on what's inside a ticket, see my previous post on the eShop/CDN (linked up above). The important details are that tickets contain the Title ID of the game they certify, the Device ID of the console they authorize, the Nintendo Account ID used to purchase them, and are signed by Nintendo using RSA-2048 (cannot be forged).
- In this case, your console talks to the "es" service, and sends a command to retrieve an encrypted copy of the relevant ticket along with the encryption key. This encryption is AES-128 CBC, using a key randomly generated via cryptographically-secure random number generation. The key itself is encrypted using RSA-OAEP 2048
- . To skip over some technical details, this is a one-way encryption which only Nintendo can reverse, so even if you obtained the output of the es command you would not be able to determine the encryption key being used (and thus couldn't decrypt the ticket).
- The data uploaded to aauth in this case is "application_id=%016llx&application_version=%08x&device_auth_token=%.*s&media_type=DIGITAL&cert=%.*s&cert_key=%.*s", formatted with the title ID for the game being played, the version of the game being played, the token retrieved from dauth, the encrypted ticket encoded with url-safe base64, and the encrypted key encoded with url-safe base64.
- This code lives at .text+0x7DE98 for 5.0.0 account.
And that's that (with the additional case where if the console fails to find a certificate, a special "NO_CERT" request is sent, but this is pretty irrelevant because sending a NO_CERT request gets your console banned). In both relevant cases, aauth validates the certification, and returns a token only if the certification is valid.
Practical Impact
These are
extremely strong anti-piracy measures -- Nintendo did a great job, here.
In the gamecard case, Nintendo can detect whether or not the user connecting has data from a Nintendo-authorized gamecard for the correct title. This solves the 3ds-era issue of gamecard header data being shared between games. Additionally, there's a fair amount of other, unknown (encrypted) data in a certificate being uploaded -- and certificates are also linked to Nintendo Accounts when gold points are redeemed. Sharing of certificates should be fairly detectable, for Nintendo.
In the digital game case, Nintendo actually
perfectly prevents online piracy here. Tickets cannot be forged, and Nintendo can verify that the device ID in the ticket matches the device ID for the client cert connecting (banning on a mismatch), as well as that the account ID for the ticket matches the Nintendo Account authorizing to log in. Users who pirate games definitionally cannot have well-signed tickets for their consoles, and thus cannot connect online without getting an immediate ban -- this is exactly how I would have implemented authorization for digital games, if I were them.
tl;dr: Don't pirate games -- it will lead to your console being banned from going online, and every banned early-hardware-revision switch is an enormous waste.
You arent'? 
