Context

Historical context

In July, 2021, the phenomenon known as the “Gigaleak” continued. The Gigaleak was a drip-feed of part of the ill-gotten data from the 2018 Nintendo data breach. On July 20, 2021, the iqcvs.tar.xz file was uploaded to the now-defunct file sharing website anonfiles.com and thereby made available to the public by The Hacker Known as 4chan. This file contains a dump of CVS repositories. The repository sw contains the BroadOn network infrastructure around the middle of the year 2006. This is shortly before the Nintendo Wii launched.

The network infrastructure was initially launched alongside the iQue Player, a variant of the Nintendo 64 featuring downloadable games and some anti-piracy measures of questionable quality (non-HTTPS link) intended for the Chinese market, which was and still is notorious for being particularly prone to piracy. It was developed by a company then called BroadOn Communications Corp., a California corporation.

The iQue Player utilized iQue memory cards. These memory cards were used such that each copy of a title was personalized for each console. This initially occurred at kiosk stations called iQue Depots. Later, the Windows software iQue@Home (神游在线) allowed users to download titles from the iQue servers in the comfort of their own homes.

BroadOn would later go on to extend the network infrastructure of the iQue and repurpose it for use with the Nintendo Wii. It would also write the Nintendo Wii operating system, IOS. In 2010, BroadOn Communications Corp. renamed itself to iGware Inc. Two years later, Acer Cloud Technology Inc., also a California corporation, acquired iGware Inc. and thereafter merged with it. Acer maintained the network infrastructure code. At some unknown point in time, Nintendo appears to have acquired the rights to modify the code, forking it into a Nintendo branch and an Acer branch. It is difficult to ascertain if there was mutual sharing of code post-fork.

Throughout the development of the system, the fundamental concepts largely stayed unchanged. There are thus only few major historical events of note. Starting with the 3DS in 2011, transferring of data between consoles have become possible. Previously, the system operated under the assumption of device uniqueness. Data transfers do not per se break the concepts of the system, but are just extra work to support. The Wii U had a rather idiosyncratic method of storing contents, which involved hash trees, which did require in large part special handling in the content distribution parts in particular. Nintendo largely abandoned the BroadOn system on favor of one of its own making starting with the Switch in 2017. However, due to rampant piracy involving an oversight in access control to contents, Nintendo would go back and patch (or have Acer patch?) the oversight in 2018.

In this post, I will examine one particular aspect of the BroadOn system: value tokens.

(Aside: The source code seems to be reasonably complete and includes database schemata. I believe it would be feasible to resurrect an actually nearly period-accurate Wii-era network infrastructure with reasonable amounts of effort. If you actually were to do that, I'd say it would be “pretty cool.” Doing so, however, depends on an Oracle database, so lacking access to one, one might have to rewrite sizeable amounts of Oracle SQL to another SQL dialect. Then again, if you're willing to touch leaked source code, you're probably also willing to pirate 20-year old Oracle database software.)

Definition

I define value tokens to refer to strings of alphanumeric digits that represent a fixed quantity of monetary or material worth. They also behave like a bearer instrument, i.e., when submitted to the intended data processing system, the represented value is made immediately available to the submitter with no identity binding prior to submission.

Well-known examples of this are Steam keys, the digits on Wii Shop Channel points cards, Windows product keys, Steam CD keys and PaysafeCard voucher numbers. If you have a fetish for these things, there is a selection for your viewing pleasure:

• 5275-3723-8388-1841
• W6M7J-6Y9FJ-XPVFB-3W7Y3-KF78Q
• XD45R-GFT51-RSD34

On the other hand, credit card and debit card numbers are not value tokens. They fail two of the criteria:

1. They represent a variable quantity of material worth.
2. They require additional tokens (notably the card security code) to be usable, thereby not behaving like a bearer instrument.

A value token representing material worth implies it cannot just reference an item. A Steam AppID references a game or application. It does not represent a fixed value. A Steam key encapsulates an AppID and represents the value of one copy of said game or application. A value token is therefore individualized.

A bearer authentication token, even if it allows access to the fixed quantity of monetary or material worth, is also not a value token. It does not have the bearer token property: An authentication token is (by definition) intended for authentication, which implies identity binding.

Prior work

Value tokens are a practical necessity. Despite this, academic literature has not paid much attention to value tokens as such. I am unaware of any commonly accepted term or definition.

There have been patents in the space. For example, a cursory search yields that Microsoft has filed patents US6209093B1 and US7512232B2. The former contains a “technique for producing a privately authenticatable product copy indicia and for authenticating such an indicia.” The latter is essentially highly distilled cryptonerd babble but explicitly references the former.

Worse yet, much research happens behind closed doors. After all, any public information increases the likelihood that an attacker is successful and can generate fraudulent value tokens or (perhaps more likely) subvert the validation mechanism.

Meet the ECard

The ECard is a concept in the BroadOn network infrastructure that encompasses a value token. It has the following attributes:

1. 63-bit ID
2. type (e.g. a 2000 Wii Points Card)
3. digital signature (internally referred to as a “hash”)
4. balance
5. flag if it is currently usable
6. timestamp of last usage
7. timestamp when it was activated
8. timestamp of when it was revoked (if at all)

The ECard is referenced with its ID, a 16-digit alphanumeric code. The first 8 digits are a sequential ID. The rest are random.

Generating ECards is meant to occur in batches, by default in batches of 10,000. Creating cards in batches was necessary for multiple reasons. First and foremost: It is a slow process. The digital signature is generated using RSA-1024 PKCS#1 with a hardware security module (HSM) for every single ECard. BroadOn used an nCipher nSHIELD F2 (nC4022W-150) device at the time. According to the product specifications, it could do 150 operations of 1024-bit RSA per second, so a batch would take over an hour to generate and sign. Additionally, they would rotate the signing key every 4,000,000 ECards or 365 days, whichever came first.

(Aside: A modern Nitrokey NetHSM can do around 1680 operations of 2048-bit RSA per second. Today, asynchronous batch processing would most likely no longer be necessary today for these quantities.)

When turning the batches into cards, the default size was 1000 lots, each consisting of by 100 packs.

The Mystery

What has been stumping me: Why were they signing every individual ECard? What is the threat model?

Broadly speaking, there are five parties involved: iQue (the entity in China), BroadOn, the printer, the actual distribution channels and the user. When iQue was running low on cards, they would get a quote from the printer and then request new ones from BroadOn, who would then supply the information for the printing company. I can think of these threats:

1. User randomly guesses a valid ECard ID input. This is mitigated by the random component and rate limiting.
2. Distribution channel is stolen from. This is mitigated by deactivating all ECards in affected packs; support then individually generates new ones for affected packs on request.
3. Rogue employee at distribution channel takes a card and makes a replica or printer records ECard information without destroying it. This leads to a support call and narrows it down to the rogue employee at the distribution channel or printer. Signing the ECard makes no difference since it still comes down to having a valid ECard ID.
4. Rogue employee at printer holds back a pack or under-fills a pack by one card. This is noticed at the distribution channel site by observation. This is mitigated by deactivating all affected ECards.
5. Rogue employee at iQue manipulates the database. This is impossible because iQue needs to request from BroadOn.
6. Rogue database administrator (DBA) at BroadOn manipulates the database so that a previously-used ECard becomes usable once more. This is mitigated by keeping immutable transaction logs and regular audits.
7. Rogue DBA at BroadOn manipulates the database so that a new ECard is inserted and is unable to obtain credentials to anything that can access the ECard signer. This is mitigated by signing ECards.

However, even given threat 7, I cannot see the necessity of signing every individual ECard. It seems more efficient to sign a batch or a lot of ECards, then check for membership in a signed batch or lot. This still guards against rogue insertions but is significantly less computationally expensive. Furthermore, given a reasonable amount of batches, this allows the verifier to cache the validation result.

If anybody is intimately familiar with the threat models of such supply chains, I would greatly appreciate any insight into the threat modeling here.