NOTE: We cannot use standard SHA-256 for the Negative List. Government ID numbers (SSNs, Driver’s Licenses) have limited entropy and predictable formats. If the Negative List database ever leaked, a standard SHA-256 hash would be cracked by a GPU cluster in minutes (Rainbow Table attack). We need a memory-hard function (Argon2id) combined with a secret keyed component (Pepper) stored in a Hardware Security Module (HSM). This ensures that even if the database is stolen, the attacker cannot reverse the identities without also physically breaching the Authority’s secure facility to get the key. (Please attack this assumption)

DRAFT ADMINISTRATIVE RULES: MINNESOTA DEPT. OF COMMERCE

Chapter: 2885 (Proposed)

Subject: Technical Standards for Digital Trust & Negative List Privacy

Authority: Minn. Stat. § 325M.01, Subd. 19; § 325M.02, Subd. 4

2885.0100 PURPOSE AND SCOPE.

The purpose of this chapter is to establish the technical specifications for the "Nonreversible Identity Token" required for the operation of the Negative List under the Minnesota Digital Trust & Consumer Protection Act. These rules are designed to ensure that the Negative List functions as an effective fraud-prevention tool without creating a central database of government identifiers that could be exploited for mass surveillance or identity theft.

2885.0200 DEFINITIONS.

Subpart 1. Input Identifier. "Input Identifier" means the raw government-issued identifier (e.g., Driver’s License Number, Passport Number) combined with the issuing jurisdiction code, normalized according to the standard defined in Subpart 3.

Subpart 2. Global Salt. "Global Salt" means a random string of data, not less than 256 bits in length, generated annually by the Authority and publicly published to allow Relying Parties to synchronize their local watchlists.

Subpart 3. Authority Pepper. "Authority Pepper" means a high-entropy secret key, not less than 256 bits, generated and stored exclusively within a FIPS 140-3 Level 3 certified Hardware Security Module (HSM) controlled by the Authority.

2885.0300 TOKENIZATION STANDARD.

Subpart 1. Algorithm Selection.

The Nonreversible Identity Token shall be generated using the Argon2id password hashing function (IETF RFC 9106). The Authority may update this algorithm by interpretive guidance if the National Institute of Standards and Technology (NIST) issues a deprecation warning for the algorithm.

Subpart 2. Parameter Requirements.

To prevent brute-force reversal of tokens derived from low-entropy identifiers (such as sequential ID numbers), the hashing process must utilize the following parameters:

A. Memory Cost: Minimum 64 MiB (m=65536).

B. Time Cost: Minimum 2 passes (t=2).

C. Parallelism: Minimum 2 threads (p=2).

D. Output Length: 32 bytes (256 bits).

Subpart 3. Construction of the Token.

The Token $T$ shall be derived as follows:

$$T = \text{Argon2id}(\text{pass} = \text{Input Identifier}, \text{salt} = \text{Global Salt}, \text{secret} = \text{Authority Pepper})$$

Subpart 4. Normalization of Input.

Before hashing, all Input Identifiers must be normalized:

A. Case: Converted to uppercase.

B. Whitespace: All spaces, hyphens, and special characters removed.

C. Format: Concatenated string of [ISO-3166-Country-Code] + [Subdivision-Code] + [ID-Number].

(Example: A Minnesota DL would be formatted as "US-MN-D12345678")

2885.0400 LIFECYCLE MANAGEMENT.

Subpart 1. Pepper Rotation.

The Authority shall rotate the Authority Pepper not less than once every 36 months, or immediately upon detection of any compromise of the HSM.

Subpart 2. List Regeneration.

Upon rotation of the Pepper, the Authority must regenerate all Tokens on the Negative List and push the update to all Authorized Issuers within 24 hours. Old tokens must be deprecated and removed from circulation.

2885.0500 PROHIBITION ON RAINBOW TABLES.

Subpart 1. Prohibition.

It is a violation of this chapter for any Authorized Issuer or Relying Party to pre-compute or generate "Rainbow Tables" (pre-calculated lists of hashed values) for the entire population of a jurisdiction for the purpose of reverse-engineering the Negative List.

Subpart 2. Targeted Hashing Only.

Relying Parties may only generate a Token for a specific Subject at the time of a transaction or application for the specific purpose of checking that Subject against the Negative List.

2885.0600 AUDIT AND COMPLIANCE.

Subpart 1. HSM Audit.

The Authority shall contract with an independent, accredited cybersecurity auditor to verify the integrity of the Hardware Security Module (HSM) holding the Authority Pepper annually. The auditor must certify that the Pepper has not been extracted, exported, or accessed by unauthorized personnel.