What Emerged Where Resident Registration Numbers Disappeared — The Identity of CI (Connecting Information) 🔐

May 14, 2026

—

“Your resident registration number may have disappeared, but its shadow still lingers on the internet.”

🎯 What this article covers

What CI (Connecting Information) is and why it was created
Why CI is 88 bytes — The secret of the hash algorithm
CI generation process (Resident Registration Number → HMAC → Base64)
CI vs DI, differences and their respective uses
Controversies surrounding CI and personal information protection

📌 Introduction / Background — What arose from the attempt to abolish resident registration numbers

In 2014, South Korea fundamentally prohibited private companies from collecting resident registration numbers. This was against the backdrop of repeated large-scale personal information leaks over several years. Credit card companies, telecommunication companies, shopping malls — resident registration numbers were accumulated everywhere, and tens of millions of records were leaked each time they were breached.

However, a problem arose. If resident registration numbers couldn’t be used, how would one verify online if “this person is the same as that person”? For example, when shopping mall A and point app B link their affiliated services, a means was needed to confirm if “Hong Gildong” who subscribed to both services was the same individual.

This led to the birth of CI (Connecting Information).

CI is used to identify the same individual between different internet companies online, and it is an 88-byte piece of information generated by an identity verification agency encrypting the resident registration number.

🔍 What exactly is CI?

Definition of CI

CI (Connecting Information) is a unique, universal Key value for identifying a specific individual. Since it is generated based on the resident registration number, its uniqueness is guaranteed, and because it uses one-way encryption, decryption is impossible.

Simply put, it’s an 88-character string created by hashing the resident registration number and then Base64 encoding it.

An example of an actual CI value looks like this:

wEi9oYSuekQGxT9MV4rKHG4CO+Zrp+onhLIIuembI8jx/0PLF5Ne3oMBxvUFlN4UmsgjeNErZfmpCVUFH..

It’s an 88-character string mixed with uppercase and lowercase English letters + numbers + special characters (+, /, =). Have you seen this before? That’s right. It’s the distinctive form of Base64 encoding.

Why 88 bytes?

Here’s the answer to the previous question. 88 bytes is the size that results when SHA-512 hash output is Base64 encoded.

The SHA-512 encryption algorithm is used as the hash algorithm.


Step	Description	Size
SHA-512 Hash Output	512 bits = 64 bytes (binary)	64 bytes
Base64 Encoding	3 bytes → 4 characters conversion	64 × 4/3 ≈ 88 characters

In other words, it’s not SHA-256, but the SHA-512 + Base64 combination that results in 88 bytes. ✅

🔧 CI Generation Process — Step-by-step breakdown

The first step is to combine the resident registration number (RN) with a secret key (SA, SK). Here, the secret key is a 64-byte secret information shared between the identity verification agency and KISA. The second step is to encrypt the combined value of the resident registration number and the secret key using a one-way encryption algorithm, a hash function.

To summarize, it is as follows:

주민번호 + KISA 공유 비밀키(64바이트)
        ↓
   HMAC-SHA-512 (일방향 해시)
        ↓
    64바이트 바이너리
        ↓
   Base64 인코딩
        ↓
    CI (88바이트 문자열)

The key here is that it uses HMAC (Hash-based Message Authentication Code) rather than a simple hash. HMAC generates a hash by mixing it with a secret key, so only KISA and identity verification agencies can reproduce the same CI.

Python pseudo-code example

import hmac
import hashlib
import base64

# Resident Registration Number + KISA Shared Secret Key
resident_number = "9001011234567"
secret_key = b"KISA_SHARED_SECRET_64BYTES_..."  # Actual secret key is not disclosed

# Generate hash with HMAC-SHA512
hmac_result = hmac.new(
    secret_key,
    resident_number.encode("utf-8"),
    hashlib.sha512
).digest()  # 64-byte binary

# Base64 encoding → 88-character CI generation
ci = base64.b64encode(hmac_result).decode("utf-8")
print(f"CI 길이: {len(ci)}")  # 88
print(f"CI: {ci}")

⚠️ The actual KISA secret key is never disclosed. The code above is pseudo-code for conceptual understanding.

🆚 CI vs DI — What’s the difference?

DI stands for Duplication Information and is a 64-byte piece of information. It refers to duplicate subscriber information within a service, and only one DI exists for a single service. Since the DI for each service is different, CI information must be used to link services with each other.


Item	CI (Connecting Information)	DI (Duplication Information)
Acronym	Connecting Information	Duplication Information
Size	88 bytes	64 bytes
Uniqueness	Same across all services nationwide	Same only within the same service
Purpose	Connecting the same individual across services	Preventing duplicate registrations within a specific service
Resident Reg. No. Matching	1:1 matching	Varies by site

Simple analogy: CI is like a nationwide ID used everywhere, similar to a resident registration number, while DI is a membership number valid only on a specific site.

⚠️ Precautions / Controversies surrounding CI

1. The “Second Resident Registration Number” Problem

Connecting Information is generated by converting the resident registration number using a hash function and adding ‘shared secret information between identity verification agencies’. Once assigned, it cannot be changed unless the resident registration number is changed, making it virtually a second resident registration number.

2. Inability to respond in case of leakage

CI was introduced to eliminate resident registration numbers, but by matching 1:1 with resident registration numbers, personal identification became possible with CI. Even if it is leaked, the individual has no right to modify it, so there is no way to respond.

3. Obligation to encrypt under the Personal Information Protection Act

Personal information handlers must securely store resident registration numbers through encryption measures to prevent loss, theft, leakage, forgery, alteration, or damage. Failure to implement encryption measures in violation of this can result in a fine of up to 30 million won.

Since CI also constitutes personal information, service providers must store CI in their databases encrypted with secure algorithms such as AES-256.

Generally, using AES-256, SHA-256 or higher leaves no room for controversy.

✅ Summary / Conclusion


Item	Content
CI Definition	Resident registration number-based one-way hash connecting information
Hash Algorithm	HMAC-SHA-512
Size	64 bytes (binary) → Base64 → 88 bytes
Decryption Possible?	❌ No (one-way)
Generation Entity	Identity verification agencies (NICE, KCB, mobile carriers, etc.)
Legal Regulation	Subject to encryption obligation under the Personal Information Protection Act

CI was born as an alternative to resident registration numbers, but it is essentially a permanent identifier that corresponds 1:1 with resident registration numbers. It remains controversial from a personal information protection perspective and is a core concept for understanding Korea’s unique identity verification system.

If you wish to delve deeper, we recommend referring to the KISA Identity Verification Support Portal and the Guidelines for Securing the Safety of Personal Information (October 2024 edition).