High-Concurrency Phone Encryption: Blind Index, KMS Management & Rotation

Problem definition

Storing a phone number (or any other personal identifier) must satisfy six constraints in a high‑concurrency micro‑service environment:

Confidentiality : the raw value must not be readable if the database is leaked.

Exact searchability : login, registration and uniqueness checks need an equality query without a full‑table scan.

Performance : encryption/decryption must add negligible latency to the critical path.

Zero‑downtime rotation : keys must be replaceable without stopping the service.

Governability : key lifecycle, permissions and audit logs must be traceable.

Extensibility : the same mechanism should be reusable for email, ID numbers, bank cards, etc.

Threat model and why simple tricks fail

Typical attacks include database file or backup theft, SQL‑injection, insider key access, log leakage, hard‑coded keys and side‑channel data stores (cache, MQ, search index). Transparent Data Encryption (TDE) only protects data at rest; it does not stop an attacker who can query the database through a legitimate connection.

Common but insecure approaches:

Random AES‑GCM encryption – provides confidentiality but makes equality queries impossible because each ciphertext differs.

Fixed IV or ECB mode – enables equality queries but leaks frequency information and enables cross‑system correlation.

Plain SHA256(phone) as an index – searchable but trivially enumerable because the phone number space is small.

Core design: blind index + envelope encryption

The production‑grade solution separates the encrypted data column from a searchable blind index.

phone_plain ──► normalise ──► ┌─────────────────────┐
                               │                     │
                               │   AES‑256‑GCM       │
                               │   (random IV, DEK) │
                               │                     │
                               └─────────────────────┘
                                      │
                                      ▼
                               phone_ciphertext

phone_plain ──► normalise ──► HMAC‑SHA256(indexKey, normalisedPhone)
                                      │
                                      ▼
                               phone_blind_index

Columns stored in the table: phone_ciphertext – AES‑GCM ciphertext, used for display or SMS sending after decryption. phone_blind_index – HMAC‑SHA256 result, stored as BINARY(32) for fast equality lookup. key_version – version of the data‑encryption key (DEK) that produced the ciphertext. index_version – version of the blind‑index key (BIK) that produced the index. phone_last4 – optional masked suffix for UI, never used in queries.

Key hierarchy

KMS Root Key
 └── KEK (Key Encryption Key)
      ├── DEK‑v1 / DEK‑v2 / …
      └── BIK‑v1 / BIK‑v2 / …

DEK encrypts the phone number, BIK creates the blind index. Keeping them separate prevents a single key compromise from exposing both the ciphertext and the ability to compute indexes.

Phone normalisation

All variants of the same logical number (e.g. +86 13800000000, 86‑13800000000, 138 0000 0000) are converted to a canonical E.164‑style numeric string before any cryptographic operation. Normalisation is the first step for both encryption and index computation.

Database schema (MySQL / TiDB example)

CREATE TABLE user_account (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    tenant_id BIGINT NOT NULL,
    phone_ciphertext VARBINARY(128) NOT NULL COMMENT 'Encrypted phone, format: iv|ciphertext|tag',
    phone_blind_index BINARY(32) NOT NULL COMMENT 'HMAC‑SHA256 blind index',
    key_version SMALLINT NOT NULL COMMENT 'DEK version',
    index_version SMALLINT NOT NULL COMMENT 'BIK version',
    phone_last4 CHAR(4) DEFAULT NULL COMMENT 'Masked suffix for UI',
    status TINYINT NOT NULL DEFAULT 1,
    created_at DATETIME(3) NOT NULL,
    updated_at DATETIME(3) NOT NULL,
    UNIQUE KEY uk_tenant_phone_index (tenant_id, phone_blind_index),
    KEY idx_created_at (created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Component breakdown (Java example)

PhoneCanonicalizer

– normalises raw input. KeyRing – in‑memory map of version → CryptoKeyMaterial, supports hot refresh and multi‑version reads. PhoneCryptoService – encrypt, decrypt, compute blind index, pack IV + ciphertext. UserRepository – DAO with methods for insert, unique‑index lookup, batch lookup, and version‑guarded update. UserRegistrationService – writes a new row using the current ACTIVE key version; catches DuplicateKeyException to report “phone already exists”. UserQueryService – for login, computes blind indexes for all readable versions, fetches candidates, decrypts each, verifies exact match, and triggers read‑time migration if the row uses an old version. PhoneMigrationService – performs read‑time migration by re‑encrypting the phone with the current key and updating the row with a version‑guarded UPDATE statement.

KeyRing implementation (simplified)

public class KeyRing {
    private final Clock clock;
    private final Map<Short, CryptoKeyMaterial> materials = new ConcurrentHashMap<>();

    public KeyRing(Clock clock) { this.clock = clock; }

    public void refresh(List<CryptoKeyMaterial> latest) {
        Map<Short, CryptoKeyMaterial> newMap = latest.stream()
            .collect(Collectors.toMap(CryptoKeyMaterial::version, i -> i));
        materials.clear();
        materials.putAll(newMap);
    }

    public CryptoKeyMaterial currentWriteKey() {
        Instant now = clock.instant();
        return materials.values().stream()
            .filter(m -> m.status() == KeyStatus.ACTIVE)
            .filter(m -> !m.activateAt().isAfter(now))
            .max(Comparator.comparingInt(CryptoKeyMaterial::version))
            .orElseThrow(() -> new IllegalStateException("no active write key"));
    }

    public CryptoKeyMaterial get(short version) {
        CryptoKeyMaterial m = materials.get(version);
        if (m == null) throw new IllegalStateException("unknown key version: " + version);
        return m;
    }

    public List<CryptoKeyMaterial> readableKeys() {
        return materials.values().stream()
            .filter(m -> m.status() != KeyStatus.RETIRED)
            .sorted(Comparator.comparingInt(CryptoKeyMaterial::version).reversed())
            .toList();
    }
}

PhoneCryptoService (core methods)

public class PhoneCryptoService {
    private static final int GCM_IV_LENGTH = 12;
    private static final int GCM_TAG_BITS = 128;
    private final KeyRing keyRing;
    private final PhoneCanonicalizer canonicalizer;
    private final SecureRandom secureRandom = new SecureRandom();

    public EncryptedPhone encrypt(long tenantId, String rawPhone) {
        String phone = canonicalizer.canonicalize(rawPhone);
        CryptoKeyMaterial km = keyRing.currentWriteKey();
        byte[] iv = new byte[GCM_IV_LENGTH];
        secureRandom.nextBytes(iv);
        byte[] aad = buildAad(tenantId, "phone");
        byte[] ciphertext = encrypt(km, phone, iv, aad);
        byte[] blindIndex = blindIndex(km, phone);
        String last4 = phone.substring(phone.length() - 4);
        return new EncryptedPhone(pack(iv, ciphertext), blindIndex,
                km.version(), km.version(), last4);
    }

    public String decrypt(long tenantId, byte[] packedCiphertext, short keyVersion) {
        CryptoKeyMaterial km = keyRing.get(keyVersion);
        byte[] aad = buildAad(tenantId, "phone");
        ByteBuffer buf = ByteBuffer.wrap(packedCiphertext);
        byte[] iv = new byte[GCM_IV_LENGTH];
        buf.get(iv);
        byte[] ct = new byte[buf.remaining()];
        buf.get(ct);
        try {
            Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
            cipher.init(Cipher.DECRYPT_MODE, km.dek(), new GCMParameterSpec(GCM_TAG_BITS, iv));
            cipher.updateAAD(aad);
            return new String(cipher.doFinal(ct), StandardCharsets.UTF_8);
        } catch (GeneralSecurityException e) {
            throw new IllegalStateException("decrypt phone failed", e);
        }
    }

    public byte[] computeBlindIndex(String rawPhone, short indexVersion) {
        String phone = canonicalizer.canonicalize(rawPhone);
        CryptoKeyMaterial km = keyRing.get(indexVersion);
        return blindIndex(km, phone);
    }

    private byte[] blindIndex(CryptoKeyMaterial km, String phone) {
        try {
            Mac mac = Mac.getInstance("HmacSHA256");
            mac.init(km.indexKey());
            return mac.doFinal(phone.getBytes(StandardCharsets.UTF_8));
        } catch (GeneralSecurityException e) {
            throw new IllegalStateException("compute blind index failed", e);
        }
    }

    private byte[] encrypt(CryptoKeyMaterial km, String phone, byte[] iv, byte[] aad) {
        try {
            Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
            cipher.init(Cipher.ENCRYPT_MODE, km.dek(), new GCMParameterSpec(GCM_TAG_BITS, iv));
            cipher.updateAAD(aad);
            return cipher.doFinal(phone.getBytes(StandardCharsets.UTF_8));
        } catch (GeneralSecurityException e) {
            throw new IllegalStateException("encrypt phone failed", e);
        }
    }

    private byte[] buildAad(long tenantId, String field) {
        return (tenantId + ":" + field + ":v1").getBytes(StandardCharsets.UTF_8);
    }

    private byte[] pack(byte[] iv, byte[] ct) {
        ByteBuffer buf = ByteBuffer.allocate(iv.length + ct.length);
        buf.put(iv);
        buf.put(ct);
        return buf.array();
    }
}

Zero‑downtime key rotation

Each key version can be in one of three states:

ACTIVE – used for new writes and allowed in reads.

DEPRECATED – no longer written, but still readable for existing rows.

RETIRED – all data migrated; the version can be removed.

Rotation workflow

Pre‑distribution : publish new key metadata to the configuration centre with status=ACTIVE and a future activate_at timestamp (or publish as DEPRECATED for a warm‑up period).

Instance hot‑load : every service instance pulls the metadata, decrypts the KEK via KMS, and stores the plaintext DEK/BIK in its local KeyRing. No traffic is affected yet.

Switch writes : when activate_at arrives, KeyRing.currentWriteKey() returns the new version, so all subsequent inserts use it.

Dual‑version queries : login/lookup code computes blind indexes for both ACTIVE and DEPRECATED versions, guaranteeing that old rows are still found.

Read‑time migration + background batch :

Hot data is upgraded on the fly when accessed (read‑repair).

Cold data is migrated by a scheduled batch job that updates rows with a version‑guarded UPDATE (see below).

Retire old key : after monitoring confirms zero reads of the old version and the migration backlog is empty, mark the old version RETIRED and remove it from the config centre.

Version‑guarded update (idempotent)

UPDATE user_account
SET phone_ciphertext = ?,
    phone_blind_index = ?,
    key_version = ?,
    index_version = ?,
    phone_last4 = ?,
    updated_at = NOW(3)
WHERE id = ?
  AND key_version = ?
  AND index_version = ?;

The WHERE clause guarantees that concurrent migrations do not overwrite each other.

Batch re‑encryption job

Typical characteristics:

Scan rows where key_version = oldVersion using a primary‑key cursor (no OFFSET).

Fixed batch size (e.g. 500‑1000 rows) and small transactions.

Rate‑limit (e.g. 200 QPS) to stay out of peak traffic.

Idempotent – the same row can be processed again without side effects.

Example Kubernetes CronJob definition:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: phone-reencrypt-job
spec:
  schedule: "0 3 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: reencrypt
              image: company/security-job:1.0.0
              args:
                - "--field=phone"
                - "--from-key-version=3"
                - "--batch-size=500"
                - "--max-qps=200"

High‑concurrency optimisations

Never call KMS or the config centre per request – keys are cached in the local KeyRing.

Reuse Cipher and Mac instances via ThreadLocal or object pools to avoid allocation overhead.

Store the blind index as binary BINARY(32) instead of a hex string.

Keep the IN list short (usually 1‑2 active versions) for query performance.

For bulk imports, normalise and compute ciphertext/blind index in the application layer, then write in controlled batches.

Multi‑tenant / sharding considerations

Two common patterns:

Unique index (tenant_id, phone_blind_index) – query includes tenant first.

Separate locator table phone_locator(tenant_id, blind_index → user_id, shard_id) – avoids cross‑shard broadcasts for massive batch matches.

KMS key governance

Layers and responsibilities:

Root Key – stored in KMS/HSM, never leaves the security boundary.

KEK – decrypted by KMS at instance start, lives only in process memory, unwraps DEK/BIK.

DEK/BIK ciphertext – stored in a configuration/secret store, versioned.

DEK/BIK plaintext – kept only in the JVM heap of the service that needs it.

Principle of least privilege: service accounts can only decrypt keys they are authorised for; ops/DBA never see plaintext keys; developers use test‑environment keys locally.

Key‑metadata JSON example (stored in the config centre):

{
  "field": "phone",
  "activeVersion": 5,
  "keys": [
    {"version": 4, "status": "DEPRECATED", "activateAt": "2026-05-01T00:00:00Z", "encryptedDek": "base64...", "encryptedIndexKey": "base64..."},
    {"version": 5, "status": "ACTIVE", "activateAt": "2026-05-08T02:00:00Z", "encryptedDek": "base64...", "encryptedIndexKey": "base64..."}
  ]
}

Observability & alerts

Essential metrics (Prometheus‑style names):

crypto_phone_encrypt_latency

crypto_phone_decrypt_latency

crypto_phone_blind_index_latency

crypto_phone_query_candidate_count

crypto_key_version_usage_total

(per version read/write count)

crypto_key_unknown_version_total

crypto_rotation_migration_total

crypto_rotation_remaining_records

Typical alert conditions:

Any occurrence of unknown key version.

Reads of a RETIRED version.

Write‑percentage of the new version stays below an expected threshold during the rotation window.

P99 encryption/decryption latency spikes.

Migration backlog does not decrease over a configurable period.

Common pitfalls checklist

Skipping phone normalisation – leads to duplicate accounts and login failures.

Storing the blind index as a VARCHAR or hex string – inflates storage and slows index scans.

Keeping only a single key version – makes zero‑downtime rotation impossible.

Hard‑coding KEK/DEK in images, CI pipelines or config files – a leak compromises the whole system.

Relying solely on TDE – does not protect against query‑time leakage.

Running a full‑table re‑encryption without throttling – causes replica lag, undo/redo log explosion, and possible outages.

Scope and limitations

The design solves exact‑match use cases for phone, email, ID, bank card, etc., in high‑throughput registration/login scenarios with strict compliance requirements. It does not support:

Prefix, range or fuzzy searches.

Full‑text search.

Statistical anonymisation for analytics.

Cross‑system sharing of plaintext values.

Adoption roadmap for architects

Phase 1 – Core path : implement normalisation, blind‑index generation, DEK/BIK versioning, and make login/registration work with the unique index.

Phase 2 – Governance : add config‑centre hot‑updates, the ACTIVE/DEPRECATED/RETIRED state machine, read‑time migration, background batch job, and expose the metrics/audit logs listed above.

Phase 3 – Platformisation : abstract the logic into a generic SensitiveFieldPolicy interface, provide SDKs for other fields, define organisation‑wide policies for cache, logs, MQ and export pipelines.

Six iron rules for production‑grade phone encryption

Encryption is a system‑design problem, not just an algorithm choice.

Separate data encryption (randomised AES‑GCM) from searchable indexing (HMAC‑based blind index).

Use a layered, multi‑version key hierarchy that can be hot‑updated.

Uniqueness must be enforced by a database unique index, not by application‑level checks.

Zero‑downtime rotation requires query compatibility, read‑time migration, and an incremental batch migration.

The security envelope extends beyond the database – cache, logs, search indexes and message queues must never retain the plaintext value.