CI 정책방향 의견수렴회 발표자료입니다. 본인확인의 결과로 본인확인 기관이 기업에 제공하는 연계정보인 CI에 대한 정책을 향후 어떻게 가져가야 할지에 대한 내용을 담고 있습니다. 현실을 고려할 때, CI의 일몰이나 개편은 현 시점에서는 시기상조라고 보고 있습니다. 관련 논거를 제시합니다.

1. 현재의 주민등록번호 체계는?
Source: 행정안전부 국가기록원, “국무조정 > 주민등록번호 체계 확립“, 2014. 2. 20, URL: http://www.archives.go.kr/next/search/listSubjectDescription.do?id=005060&pageFlag=
1975년 (주민등록법) 시행규칙 39차 개정에서 제1조의 내용을 “주민등록법시행령(이하 ‘영’이라 한다) 제3조의 규정에 의한 주민등록번호는 생년월일, 성별, 지역 등을 표시할 수 있
는 13자리의 숫자로 작성한다.”고 변경함으로써 현재의 주민등록번호 조합체계가 완성이 되었고, 이후 대한민국의 모든 국민은 13자리의 주민등록번호를 발급 받게 되었다.
국가기록원 – 주민등록번호 체계 확립 (2014. 2. 20)

2. 주민등록번호의 문제점?
Source: 이민영(Internet and Information Security 제2권 제1호), “주민등록번호 취급의 개인정보 보호법 정합성“, 2011. 5., p. 92-93, URL: https://www.kisa.or.kr/jsp/common/libraryDown.jsp?folder=9012207
주민등록번호는 13자리 숫자로 구성되어 있으나 생년월일, 성별, 연령, 지역 등 개인에 관한 기초 정보를 확인할 수 있으며, 자동차, 주소, 호적, 부동산, 교육, 보험 등 공공기관 대부분
의 정보는 이 기초정보를 토대로 하고 있다.
주민등록번호는 국가가 국민에게 부여하는 고유번호로 공공기관 뿐만 아니라 민간분야에서도 광범위하게 사용되고 있지만, 이와 같은 주민등록번호는 별도의 장비 없이 번호 자체만
으로도 몇몇 개인정보를 알 수 있고 다른 개인정보를 알 수 있는 키(key) 역할을 할 뿐만 아니라, 영구적으로 변하지 않기 때문에 한번 노출되면 지속적으로 프라이버시를 침해당할 가
능성이 크다.
그럼에도 불구하고 관리가 편하고 국민 누구나 가지고 있으며 상업적 가치도 크기 때문에 인터넷 홈페이지에 가입할 때 해당 가입자의 주민등록번호를 필수적으로 입력하도록 요구하
는 경우가 많다. 이렇게 주민등록번호가 여러 사이트의 데이터베이스에서 관리되면서 주민등록번호가 유출되거나 불법적으로 사용되는 등의 문제가 발생하고 있을 뿐만 아니라, 주민
등록번호를 연결고리로 한 개인의 성향이나 행태에 관한 정보를 재생산하여 상업적으로 판매하는 경우까지 등장하고 있다.
주민등록번호 취급의 개인정보 보호법 정합성 (2011. 5., 이민영)
“주민번호는 유일성, 평생불변성 등의 특징으로 인하여 한번 유출시에도 지속적인 피해가 발생할 수 있는 중요한 정보…”
주민등록번호 수집 금지 제도 가이드라인 (2014. 1. 20, 행정안전부)

3. CI (Connecting Information)은?

4. CI (Connecting Information)의 실제 모습은?
yCP7v5vRAX9GVCEmHQrzi5UtjzglzqZZlC3lGRqrdzrfJz41S0M6yxB8i7eHLgo6WGXIJ8r7hWGouc1/SBajMw==
eUJFJHEgQNSx3Ek3ePh47RKsCqAlNeSU5mXmJ/WrKEd93rT3RONSRGArmUbYMbenhc41StKP3oW1qgBGZgnfcQ==
JFcfLhljY+pWGDkDSofB6W/F6kBwQLu0j9hgC7iQ9pPju0dGQNSIBRRmtu1WPLXWvtuMCizvWBFvBFTUN4h9lg==
Real
Example
Source: S 평가정보, “아이핀 서비스 도입 제안“, 2015 (offline으로 제공되는 사업 제안서 중 발췌)

5. CI가 가장 민감하고 유일한 식별자(identifier)인가?
Source: 이진규, “인터넷 쿠키(Internet Cookie)”, 2017. 6., URL: https://www.slideshare.net/callmejk/internet-cookie

6. 왜 CI는 신뢰할 수 있는 정보인가?
 관리의 투명성
- 정부에 의한 높은 수준의 관리, 결과의 공개
 범용성
- 온, 오프라인 연계
 신뢰성
- 본인확인 절차에 의해 생성, 제공
 낮은 식별성
- 암호화된 문자열
 사용 제한성
- 본인확인, 연계, 식별 및 그에 준하는 목적 외 사용 제한 (불분명하다는 논의 존재)

7. identifier ID surname name phone age email_other
0001 beckham_01 이 나래 01087538766 44 dnoue@naver.com
0002 caist 김 요한 01099875489 32 korkor@naver.com
0003 koe3soke 박 순정 01086589377 19 koe2soke@naver.com
0004 babobabo87 윤 호경 01076549813 22 babobabo99@daum.net
0005 btsbts0101 변 ㅅ환 01085498701 24 btsforever9999@gmail.com
id_no_hashed email m_phone h_phone birth_date full_name
hs873kskqw3 dnoue@naver.com 01087538766 029876547 19750301 이나래
1xn$srkxj38 korkor@naver.com 01099875489 0348769898 19871109 김요한
sfj84_24jfs89 koe2soke@naver.com 01086589377 0529876766 20000589 박순정
1jf$$#9))00 babobabo99@daum.net 01076549813 020000000 19970517 윤호경
cd340fk26#!2 btsforever9999@gmail.com 01085498701 01085498701 20010101 변시환
마일리지, 포인트, 온오프연계 예약 등
거래관계에서의 ‘정합성’ 확인이 필요
CI의 활용이 왜 중요한가?
① A사와 B사간 공통 식별자 생성에 대해 협의 – 예) “Hash(SHA256, 이름 + 이메일 주소 + 전화번호)” 생성
- 어떤 hash algorithm을 사용할 것인가? Salting 등 추가 보안조치는 어떻게 할 것인가?
② A사와 B사건 API 를 통한 Hash Value 교환 또는 TTP를 통한 확인 업무 수탁
- API spec.은 어떻게 결정할 것인가? API 보안은 어떻게 할 것인가? 어떤 TTP와 계약을 할 것인가? TTP에 대한 수탁자 감독은 어떻게 할 것인가?
③ 매칭되지 않는 대상자에 대한 ‘예외 처리’ 절차 진행 – 예) 에러 코드 (설명) 노출 및 오프라인 본인확인 절차 진행 안내
- 매칭되지 않는 원인은 무엇인가? (부정합 데이터? 데이터 교환 과정 및 비교 과정 오류?), 부정합 데이터 확인에 대한 개인정보 3자 제공 처리는 어떻게 할 것인가? 오류에 대한 설명은 어떻게 할 것인가? 오프라인 상황 별 CS
Manual은 갖추어져 있는가?

8. DI에 의한 연계는 왜 문제가 되는가?
 Synchronization의 어려움
- 연계에 필요한 2개 이상의 사업자가 각기 보유한 DI값을 ‘연계기관’에 던져서, 양 DI가 일치한다는 회신을 받아야 함
- 이 과정에서, sync를 100 % 보장하기 어렵고 어느 한쪽의 장애로 인해 다른 한쪽까지 서비스 제공에 영향을 받는 dependency risk가 발생
- 또한, 연계기관이 모든 사업자별 / 이용자별 매칭되는 DI값의 set를 보유하고 있다는 것이 전제되어야 하는데, 이는 현실적으로 구현이 어려움
ㄴ 또는, 연계기관들이 공동의 DB Pool을 공유할 수 있으나, Single Point of Failure를 만드는 것이어서 바람직한 구현은 아님
 복잡한 DB구조의 형성 및 연계성 증대
- A라는 이용자에 대해 B, C사가 각기 다른 DI값(B사 – DI 1, C사 – DI 2)을 보유하고 있는데, 이를 ‘연계기관’에 던져서 동일인 여부를 확인하게 됨. 그런데, 향후 서비스 연계를 위해
서는 상대방이 가지고 있는 DI 값을 교환하거나 (즉, DI 1 + DI 2를 한 DB에 저장), 상대방 이용자에 부여된 식별자(identifier)를 DI와 함께 저장해야 함. 즉, (DI 1 + C사 identifier,
또는 DI 2 + B사 identifier)
- 이는 서비스 연계가 확장될 때마다 DB를 지속 확대해야 함을 의미하며, 제휴 상대방 이용자의 DI를 받아오거나, 식별자(identifier)를 받아와야 하기 때문에 결국 특정 이용자에
대한 ‘연계성’을 높이는 불합리한 결과가 발생함
- 특히 (DI 1 + DI 2 + … + DI n)은 단일한 CI를 운영하는 것에 ‘실질적으로 수렴’하는 결과를 나타내므로 DI 활용 실익이 없음

9. CI활용 실제 사례 (1)
 Broadband 제공 A사
- 제공하는 콘텐츠(영상 등)를 웹사이트가 제공(CP)하고 그에 따른 이용 기록 공동 확인
- 이용 고객에 대하여 포인트, 쿠폰 제공
- CP로부터 제공받는 콘텐츠 소비에 대한 이용자 별 통합과금 서비스 제공
 자동차 판매업 B사
- 할부금융거래를 위해 캐피탈사에게 본인확인된 정보 제공, 할부금융거래 신뢰 확보
- 카드사 적립 등의 원활한 처리를 위한 신용카드사 연계정보 제공
 간편결제 C사
- 포인트 적립 및 사용에 대한 승인 및 정산
- OO포인트 카드 관련 제휴 업무 수행
 문화재단 D
- 공연관련 결제 시, OO 제휴 포인트 적립
- 문화재단과 OO 계열사간 회원활동 통합 관리
 건설업종 E사 (채용)
- 직무능력검사 기관에서의 대상자 확인 및 결과 공유
- OO 그룹사와의 응시자 채용 전형 공통 활용
 스마트 스피커 서비스 제공 F사
- 서비스 연계된 음식배달 기업에 OOO 멤버십 연동에 따른 할인 등 대금 정산
- 은행에서의 계좌 및 거래 확인
 글로벌 리테일 G사
- 제휴카드 발급자의 확인, (탈퇴 시) 제휴 서비스 중지 및 부가정보 공유
- 제휴사간 상호 포인트 전환
 핀테크 H사
- 연계된 금융기관에서의 계좌 개설 및 본인확인
- 펀드 소액투자 서비스 제공
- 투자정보 관리 및 중복가입 방지
 온라인 서비스 제공 I사
- 판매자 중복가입 방지 및 FDS(Fraud Detection System)
- 포인트 교환 시 사용자 정보 활용
- 신용카드 등록 시 본인확인 정보 교환
- 극장 예매자에 대한 본인확인 및 포인트 적립 (또는 중복적립 제한)
[종합]
① 주민번호의 수집, 보관으로 인한 위험의 예방
② 식별성 높은 개인정보(들)의 교환 필요성 대체
③ 어뷰징 방지 및 FDS를 통한 피해 예방

10. CI활용 실제 사례 (2)
 특정금융거래법에 따른 "고객확인 의무“ 준수를 위해 고객의 ‘실지명의(실명 및 주민등록번호)‘ 확인 필요
- 전자금융업자들이 주민등록번호 수집/저장 위험성을 확인, 금융위원회에 건의 진행
- 이에, 금융위원회는 주민등록번호 대신 CI를 수집/저장할 수 있도록 특정금융거래법 시행령 및 감독규정 개정
- 법제에 의해 ‘피싱이 용이해질 수 있는 상황’을 예방한 것 (CI가 존재하지 않았다면 주민번호 수집에 따른 각종 부작용 재현될 수 있었음)
특정금융거래법제5조의2(금융회사등의 고객 확인 의무) ① 금융회사등은 금융거래를 이용한 자금세탁행위 및 공중협박자금조달행위를 방지하기 위하여 합당한 주의(注意)로서 다음 각 호의 구분에 따른 조치를 하여야 한다. 이 경우 금융회사
등은 이를 위한 업무 지침을 작성하고 운용하여야 한다. <개정 2014. 5. 28.>
1. 고객이 계좌를 신규로 개설하거나 대통령령으로 정하는 금액 이상으로 일회성 금융거래를 하는 경우: 다음 각 목의 사항을 확인
가. 대통령령으로 정하는 고객의 신원에 관한 사항
나. 고객을 최종적으로 지배하거나 통제하는 자연인(이하 이 조에서 "실제 소유자"라 한다)에 관한 사항. 다만, 고객이 법인 또는 단체인 경우에는 대통령령으로 정하는 사항
특정금융거래법시행령 제10조의4(고객의 신원에 관한 사항) 법 제5조의2제1항제1호가목에서 "대통령령으로 정하는 고객의 신원에 관한 사항"이란 다음 각 호의 구분에 따른 사항을 말한다.
1. 개인(다른 개인, 법인 그 밖의 단체를 위한 것임을 표시하여 금융거래를 하는 자를 포함한다)의 경우: 실지명의(전자금융거래의 경우 금융정보분석원장이 정하여 고시하는 고객에 대해서는 실지명의 대신 성명, 생년월일 및 성별 등 금융정보
분석원장이 정하여 고시하는 사항을 말한다), 주소, 연락처(전화번호 및 전자우편주소를 말한다. 이하 같다)
특정금융거래법감독규정 제23조(실지명의에 관한 사항) ①영 제10조의4제1호에서 “금융정보분석원장이 정하여 고시하는 고객”이란 법 제5조의2제1항제2호에 해당하지 아니한 고객으로서 다음 각 호의 어느 하나에 해당하는 자(「전자금융
거래법」제28조제1항단서 및 같은 조 제2항단서에 따른 「은행법」에 따른 은행 및 금융회사를 포함한다)와 전자금융거래를 하는 고객을 말한다.
1. 「전자금융거래법」 제28조제1항
2. 「전자금융거래법」 제28조제2항제1호부터 제4호
3. 「전자금융거래법 시행령」 제15조제3항제1호 및 제2호
② 영 제10조의4제1호에서 “금융정보분석원장이 정하여 고시하는 사항“은 다음 각 호에서 규정하는 사항을 말한다.
1. 성명, 생년월일 및 성별
2. 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」 제23조의2 제2항에 따른 대체수단 활용으로 생성된 연계정보
3. 전자금융거래를 위해 전자금융업자에 제공한 계좌번호(계좌번호가 없는 경우에는 참조 가능한 번호를 말한다)

11. CI가 없다면 어떤 문제가?
.
.
.
.
.
.
결국 N:N의 관계라는 복잡한 관계를 형성
 오류나 보안성 저하로 인한 개인정보 유출 가능성 증대
 시장 지배적 사업자가 전체 시장을 지배하는 구조로 변화
 온, 오프라인 통합 곤란 & 고객 CS 비용 증가

12. 만약 해킹으로 인해 CI가 유출된다면?
Q. “CI는 그 자체로 가치가 있나?” (X)
A. 이름, 생년월일, 주소, 연락처(휴대전화번호, 이메일 등), ID 등과 비교하여 자체적 가치가 현저히 낮음. User Interaction 단계에서 활용할 곳이 없음
A’. 데이터는 내재가치와 이용가치를 모두 고려하여 가격을 책정하는데, CI의 내재가치는 산정이 곤란하며 이용가치는 0에 가까움
Q. “다른 Identifier와 비교하여 여러 사이트의 정보를 용이하게 엮어낼 수 있나?”
A. 10개의 사이트를 해킹하는 경우, 10개 모두에 CI가 저장되어야 있어야 함. CI를 보유하고 있는 복수의 사이트를 해킹하여 이용자 정보를 엮어내야 하는 부담
A’. 어차피 CI로 여러 사이트의 정보를 엮어내더라도, 각 사이트의 회원 DB정보가 정확하다는 보장이 없음. 특히 본인확인기관이 내려주지 않는 주소 및 이메일은 정확성을 담보할 수 없기 때문에 여러 사이트 정보를 엮어내더라도
부정확한 정보가 포함될 수 밖에 없는 구조임
Q. “가장 확실한 Identifier라서 가치가 높지 않은가?”
A. CI 확보의 불확실성, (이름+전화번호+이메일 주소) 등 확보가 용이하고 결합이 쉬운 정보로 key를 생성하는 것과 비교했을 때, 범용성 및 경제성 등에서 경쟁력 없음
Q. “그래도 <본인확인이 된 정보>라는 측면에서 데이터 가치가 더 높다 볼 수 있지 않은가?”
A. 본인확인이 된 정보라도 해당 정보를 활용(예: 대출 신청, 온라인 회원가입 등)할 때에는 추가적인 본인 입증 절차가 존재하기 때문에 신분증, 본인 소유 휴대폰 등에 비해 가치가 현저히 낮음. 본인확인이 된 정보라서 가치가 높다
는 것은 입증되지 않았음. 또한 해당 CI가 ‘본인확인 결과’를 입증한다는 보장이 없음 (해커가 허위로 생성한 정보일 수도…)
[psychology] of hackers = value-centered

13. #Appendix
 Resettability
- Who(which personal identification agency) will take the blunt?
- Needs another CI generation protocol for the reset?
- How to deal with the different Cis for the same person?
ㄴ Will updating with the late-generated CI be enough?
- Are resettable identifiers truly untraceable to their predecessors?
 Transparency for the purpose of use
- Socket vs. Web Method?
- Who’s to blame?
- What should be done first?
ㄴ Revision of consent rules vs. transparency for the purpose of use
 Regulation for the fear of unrealized damage
- Analogy to kitchen knives confiscated & managed by the government?
- Paypal loss rate to frauds (0.28%) vs. Domestic companies (less than 0.1%)
ㄴ by Financial Security Institute (2018. 1. 18)
- balance between security and convenience
ㄴ The right to privacy is not an absolute right, which means it should be
balanced against other constitutional rights