550. X.509 v3 - 공개키 기반 구조(PKI)의 디지털 인증서 표준 규격

핵심 인사이트 (3줄 요약)

본질: X.509 v3는 인터넷상에서 누군가가 내민 '공개키(Public Key)'가 해커의 것이 아니라 진짜 그 사람/서버의 것임을 보증하기 위해, 절대적으로 신뢰할 수 있는 제3자 기관(CA)이 디지털 서명(도장)을 찍어 발행한 전자 신분증(디지털 인증서)의 국제 규격이다.

가치: 네이버나 구글에 접속할 때 우리가 그 서버를 의심하지 않고 비밀번호를 칠 수 있는 이유는, 브라우저가 보이지 않는 뒷단에서 서버가 제시한 X.509 인증서가 진짜인지 수학적으로 1밀리초 만에 검증하는 **'신뢰의 사슬(Chain of Trust)'**이 지구 전체의 인터넷을 지탱하고 있기 때문이다.

융합: 단순한 주체 확인(v1/v2)을 넘어 v3로 진화하며 확장 필드(Extensions)를 탑재하여, 오늘날 SSL/TLS 웹 보안(HTTPS), IPsec VPN, S/MIME 이메일 보안, 그리고 802.1X 무선랜 인증 등 현대 네트워크 보안 인프라 전체를 꿰뚫는 절대적 융합 척추로 군림하고 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: X.509는 국제 전기 통신 연합(ITU-T)에서 공개키 기반 구조(PKI, Public Key Infrastructure)의 핵심인 디지털 인증서 형식을 정의한 표준이다. 쉽게 말해 어떤 사람(또는 서버)의 "이름, 소속, 유효기간, 공개키 원본"을 묶은 뒤, 국가 공인 기관(CA)의 서명이라는 압인을 찍어 위조를 불가능하게 만든 전자 문서다.
필요성: 비대칭 암호학(RSA 등)은 기가 막힌 발명이다. 내가 철수의 공개키를 구해서 그걸로 암호화하면 철수의 개인키로만 풀 수 있다. 하지만 결정적인 허점이 있다. 중간에 몰래 숨어든 해커(Eve)가 "내가 철수야! 내 공개키 받아!"라고 던져주면, 나는 꼼짝없이 해커의 공개키로 기밀문서를 암호화해 바치게 된다(Man-in-the-Middle Attack). 공개키 자체는 수학적으로 완벽하지만, "그 공개키가 진짜 철수의 것인가?"를 증명하는 사회적 신뢰의 고리가 누락되었기 때문이다. 이를 막기 위해 등장한 것이 X.509 인증서 체계다.
등장 배경: ① 암호학 발전으로 공개키 배포 문제가 최대 화두로 대두 → ② 1988년 X.500 디렉터리 서비스의 일부로 X.509 첫 발표 → ③ 인터넷의 상업화(HTTPS 등장)와 확장성 요구 증가로 v3 확장 필드가 추가되며 전 세계 웹 브라우저의 기본 신뢰 엔진으로 정착.

┌─────────────────────────────────────────────────────────────┐
│             해커의 중간자 공격 vs X.509 신뢰 기관의 방어 체계         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   [과거: X.509 부재 시의 공개키 탈취 공격 (MitM)]                    │
│   나(Client)  ◀─── "내가 구글이야, 내 [공개키(해커꺼)] 써!" ─── 해커 │
│   => 아무 의심 없이 해커의 공개키로 비밀번호 암호화해서 바침. 재앙!         │
│                                                             │
│   [혁신: X.509 인증서와 CA (신뢰의 사슬) 도입]                       │
│                        ┌────────────────────┐         │
│   구글(Server) ─────▶│ 1. 루트 CA (예: DigiCert)│         │
│  "나 구글인데 도장 좀!"   │ 2. 검증 후 인증서에 도장 쾅!│         │
│                        └────────────────────┘         │
│                                  │                          │
│                                  ▼ 3. 발급된 인증서          │
│                                                             │
│   나(Client)  ◀──── "[구글 공개키 + 루트 CA의 철통 서명]" ──── 구글 │
│   => 내 브라우저 안에는 이미 루트 CA의 공개키가 내장되어 있음!           │
│   => 브라우저: "오, 이 도장 진짜 DigiCert가 찍은 거 맞네! 구글 진짜네!"  │
│   (해커가 가짜 인증서를 만들어 줘도, 루트 CA의 서명을 위조할 수 없어 발각됨)│
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 공개키 암호화는 자물쇠(공개키)를 상대방에게 던져주고 잠가서 돌려달라고 하는 방식이다. 해커는 중간에 끼어들어 진짜 자물쇠를 버리고 자신의 자물쇠를 클라이언트에게 던진다. X.509는 이 자물쇠에 '세계적으로 유명하고 믿음직한 보증인(Root CA)'이 끈끈하고 위조 불가능한 인증 스티커(전자 서명)를 붙여주는 것이다. 클라이언트의 PC(크롬, 사파리 브라우저 내부)에는 이미 전 세계 유명 보증인 100여 명의 도장(Root CA 인증서)이 공장 출고 때부터 탑재되어 있다. 따라서 구글이 건넨 자물쇠의 스티커를 내 PC의 도장과 수학적으로 대조해 보면, 해커의 야매 스티커는 1밀리초 만에 "안전하지 않은 연결입니다"라며 새빨간 경고창을 띄우고 즉각 차단된다.

📢 섹션 요약 비유: 모르는 사람이 "나 경찰이야"라며 명함을 줄 때 안 믿는 것이 상식입니다. 하지만 그 명함에 '대한민국 정부 홀로그램 도장(X.509 서명)'이 찍혀있다면 우리는 안심하고 수사(데이터 전송)에 협조합니다. 브라우저는 우리 대신 그 홀로그램이 진짜인지 돋보기로 비춰보는 똑똑한 감별사입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

구성 요소 (X.509 v3 인증서 내부 필드 뜯어보기)

인증서는 방대한 텍스트(Base64 PEM 포맷 등) 파일이다. 가장 널리 쓰이는 X.509 v3 규격은 다음과 같은 3단 샌드위치 논리 구조를 가진다.

필드 그룹	세부 항목	의미	예시 / 역할
기본 정보 (TBS Certificate)	Version	X.509의 버전	v3 (가장 최신 표준)
	Serial Number	발급자(CA)가 부여한 고유 번호	0x1A2B3C... (폐기 추적에 쓰임)
	Issuer (발급자)	도장을 찍어준 인증기관(CA)의 이름 (DN 형식)	`CN=DigiCert TLS RSA SHA256 2020 CA1`
	Validity (유효기간)	인증서가 법적으로 유효한 시작/끝 시간	2024.01.01 ~ 2025.01.01 (최대 398일 제한)
	Subject (주체)	이 인증서의 주인공 (소유자)	`CN=www.google.com, O=Google LLC...`
	Subject Public Key Info	가장 중요한 공개키 원본과 알고리즘	RSA (2048 bit), ECC (secp256r1)
v3 확장 필드 (Extensions)	SAN (Subject Alternative Name)	하나의 인증서로 묶어줄 다수의 도메인 이름	`*.google.com, youtube.com` 등 동시 지원
	Key Usage / EKU	공개키의 사용 목적 제한	서버 인증용, 코드 서명용, 이메일 보호용
디지털 서명 (Signature)	Signature Algorithm & Value	위 모든 정보(TBS)의 해시값을 발급자(CA)의 개인키로 암호화한 절대 위조 불가 도장	`sha256WithRSAEncryption` 결과 암호문 덩어리

체인 오브 트러스트 (Chain of Trust) - 계층적 검증 아키텍처

우리가 은행이나 대형 포털에 접속할 때 받는 인증서는 Root CA가 직접 찍어준 것이 아니다. 만약 해커가 Root CA의 개인키를 훔친다면 지구상의 모든 인터넷 신뢰가 무너지는 둠스데이(Doomsday)가 벌어진다. 그래서 Root CA는 안전한 벙커(오프라인)에 격리시키고, 그 권한을 위임받은 **중간 CA (Intermediate CA)**들이 현장에서 실무(인증서 발급)를 뛴다.

┌───────────────────────────────────────────────────────────────┐
│               X.509 신뢰 사슬 (Chain of Trust) 수학적 검증 흐름   │
├───────────────────────────────────────────────────────────────┤
│                                                               │
│   [Root CA 인증서] (내 브라우저에 이미 설치되어 있음 = 최상위 무조건 신뢰)│
│     - 주체(Subject): DigiCert Root                               │
│     - 발급자(Issuer): DigiCert Root (자기 자신, Self-signed)      │
│     - 서명: Root 개인키로 찍음                                   │
│           │                                                   │
│           │ (신뢰 위임: 서명 보증)                                │
│           ▼                                                   │
│   [중간 CA 인증서] (Intermediate CA)                             │
│     - 주체(Subject): DigiCert TLS CA 1                         │
│     - 발급자(Issuer): DigiCert Root                            │
│     - 서명: Root 개인키로 찍음 ─▶ 브라우저가 Root 공개키로 열어보고 진품 확인!│
│           │                                                   │
│           │ (신뢰 위임: 서명 보증)                                │
│           ▼                                                   │
│   [End-Entity 인증서] (서버가 나에게 전송한 인증서)                  │
│     - 주체(Subject): www.google.com                           │
│     - 발급자(Issuer): DigiCert TLS CA 1                        │
│     - 서명: 중간 CA 개인키로 찍음 ─▶ 중간 CA 공개키로 열어보고 진품 확인!  │
│                                                               │
│   결론: 꼬리에 꼬리를 무는 서명 검증을 통해 맨 꼭대기(Root)까지 올라가며,│
│         이 연결 고리가 단 하나라도 끊어지면 빨간 경고창("보안 위협")이 뜬다.│
└───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 검증 메커니즘은 보안 아키텍처의 백미다. 서버에 접속하면 서버는 딸랑 자기 인증서 하나만 주는 게 아니라, 중간 CA 인증서까지 사슬처럼 엮어서 나(클라이언트)에게 던져준다(Certificate Chain). 내 브라우저는 맨 밑단(구글) 인증서를 중간 CA 공개키로 풀어보고 "음 맞네", 그다음 중간 CA 인증서를 내 컴퓨터에 내장된 Root CA 공개키로 풀어보고 "오 Root가 보증한 게 맞네!"라며 단계적으로 신뢰의 사다리를 타고 올라간다. 만약 해커가 맨 밑단 인증서를 위조하면 중간 서명에서 실패하고, 해커가 중간 CA까지 통째로 가짜로 만들어 던지면 맨 꼭대기 내 PC에 그 가짜 Root 도장이 없기 때문에 사기극이 1초 만에 들통난다.

📢 섹션 요약 비유: 동네 파출소장(중간 CA)이 끊어준 신분증(구글 서버)을 받았을 때, "파출소장이 경찰청장(루트 CA)한테 정식으로 임명받은 게 맞나?"를 경찰청장 직인을 통해 교차 검증함으로써 가짜 신분증과 가짜 파출소장을 한꺼번에 잡아내는 릴레이 철통 방어입니다.

Ⅲ. 융합 비교 및 다각도 분석

인증서 만료 및 폐기 메커니즘 (CRL vs OCSP 비교)

아무리 완벽한 인증서라도, 발급해 준 후 서버가 해킹당해 '개인키'를 도둑맞으면 그 인증서는 흉기로 전락한다. 따라서 CA는 "이 인증서는 도둑맞았으니 믿지 마라"라고 전 세계에 알릴 수단(폐기 메커니즘)이 필요하다.

비교 기준	CRL (Certificate Revocation List)	OCSP (Online Certificate Status Protocol)
작동 원리	CA가 주기적으로 배포하는 블랙리스트 (현상수배 전단지)	클라이언트가 CA에게 "이놈 아직 괜찮아?" 실시간 묻는 프로토콜
데이터 크기	폐기된 인증서가 많을수록 리스트가 수십 메가바이트로 비대해짐	단 한 건의 인증서 일련번호만 물어보므로 매우 가벼움
지연 시간 (Latency)	브라우저가 주기적으로 큰 파일을 다운로드하므로 초기 로딩 지연 막심	매 접속마다 CA 서버 통신이 발생하여 약간의 네트워크 지연 발생
보안 공백 (Window)	전단지가 업데이트되기 전(며칠간)까지는 폐기 사실을 모름 (공백 큼)	실시간 확인 가능하나, CA 서버가 죽으면 사이트 접속이 마비되는 부작용
현대적 해결책	구형 시스템이나 폐쇄망에서 여전히 사용됨	OCSP Stapling 기술로 융합 발전 (서버가 미리 CA 응답을 받아두고 넘겨줌)

┌───────────────────────────────────────────────────────────────┐
│               OCSP Stapling 기술을 통한 지연 및 프라이버시 해결      │
├───────────────────────────────────────────────────────────────┤
│                                                               │
│   [과거: 기본 OCSP의 한계]                                       │
│   나 ──(접속)──▶ 웹 서버 (인증서 수신)                              │
│   나 ──(질의)──▶ CA 서버 (저 서버 인증서 정상인가요?) ─▶ 지연 발생, 내 흔적 노출│
│                                                               │
│   [혁신: OCSP Stapling (찍어주기)]                               │
│   1. 웹 서버가 주기적으로 CA 서버에 물어봐서 "나 아직 정상이오" 도장을 받아둠. │
│   2. 나 ──(접속)──▶ 웹 서버                                       │
│   3. 웹 서버 ───▶ [자신의 X.509 인증서] + [CA가 찍어준 정상 확인증] ──▶ 나 │
│                                                               │
│   => 클라이언트는 CA 서버를 귀찮게 찌를 필요 없이, 서버가 던져준 확인증의     │
│      CA 서명만 수학적으로 검사하면 됨! (속도 극대화, 프라이버시 보호)        │
└───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 기존 OCSP의 가장 큰 문제는 '사생활 침해'와 '단일 장애점(SPOF)'이었다. 내가 어느 사이트에 접속할 때마다 내 브라우저가 CA 서버에 일일이 물어본다면, CA 기관은 전 세계 사람들이 어느 시간대에 무슨 사이트를 들어가는지 사찰할 수 있게 되며, 만약 CA 서버가 터지면 구글 네이버 등 모든 사이트 접속이 거부당한다. 이를 해결한 **OCSP Stapling(스테이플링)**은 서버 본인이 아침에 미리 CA에 가서 "나 안전함"이라는 시간제한(Time-stamped) 도장을 받아 스테이플러로 꽉 찍어두고 방문객에게 보여주는 아키텍처다. 성능과 보안, 프라이버시 세 마리 토끼를 잡은 위대한 융합 아키텍처다.

📢 섹션 요약 비유: 매번 가게에 들어갈 때마다 손님이 보건소(CA)에 전화해 "이 가게 위생 문제없나요?" 묻는 것(기본 OCSP)은 너무 느립니다. 대신 식당 주인이 아침에 보건소에서 '오늘의 정상 영업 스티커(OCSP Stapling)'를 받아와 가게 문에 붙여두면, 손님은 스티커만 보고 바로 안심하고 밥을 먹는 똑똑한 타협안입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오: Let's Encrypt 자동화와 398일 제한에 따른 인증서 대란 (Outage) 방어

상황: 대기업 쇼핑몰에서 연말 할인 행사 날, 갑자기 브라우저 화면에 빨간색 NET::ERR_CERT_DATE_INVALID 에러가 뜨며 고객들의 결제가 100% 튕겨 수십억 원의 매출이 증발했다.
원인: 수백 개의 마이크로서비스 도메인 인증서를 엑셀로 관리하던 엔지니어가 1년짜리 X.509 인증서 갱신(Renew)을 하루 놓쳤다. 2020년 9월부터 애플과 구글 등 주요 브라우저 연합은 보안 강화를 위해 인증서의 최대 유효기간을 2년에서 **398일(약 1년)**로 강제 축소했다. (이 기간을 넘긴 인증서는 무조건 거부됨).
의사결정 및 조치 (ACME 기반 자동화 융합):
- 아키텍트는 엑셀을 버리고 'Let's Encrypt'와 같은 무료/개방형 CA가 제공하는 ACME (Automated Certificate Management Environment) 프로토콜 환경을 구축한다.
- 서버의 Nginx나 Kubernetes Ingress(Cert-manager)에 ACME 클라이언트를 심는다.
- 이 에이전트는 만료 30일 전이 되면 스스로 CA와 백그라운드 통신(DNS 또는 HTTP 챌린지)을 통해 자신의 도메인 소유권을 기계적으로 증명하고 새 인증서를 갱신해 서버를 재기동(Reload)한다.
- 결과: "인증서 만료 갱신 누락"이라는 엔터프라이즈의 가장 고질적이고 치명적인 1순위 장애 요인을 인프라 코딩(IaC)과 자동화 모듈로 영구히 제거(Zero-Touch)하였다.

도입 체크리스트 및 안티패턴

SAN (Subject Alternative Name) 다중 도메인 활용 여부 검증: 과거 구형 v1 인증서는 Common Name (CN) 필드 하나에 도메인(www.company.com)을 하나만 넣을 수 있어 서버가 여러 개면 인증서를 다 따로 사야 했다. X.509 v3부터 도입된 SAN 확장 필드를 쓰면 하나의 인증서에 app.company.com, mail.company.com 등 수십 개의 도메인을 때려 넣을 수 있다. 최신 크롬 브라우저는 CN 필드를 쳐다보지도 않고 무조건 SAN 필드만 검사하므로, SAN 누락은 무조건 보안 에러를 뿜어낸다.
안티패턴: 자가 서명 인증서(Self-Signed Certificate)를 사내 운영(Production)망에 그대로 쓰는 행위. 돈이 아깝다고 본인 서버가 본인 인증서에 스스로 도장을 찍는 구조(Root CA 흉내)다. 브라우저가 당연히 "위험한 사이트"라며 시뻘건 경고를 띄운다. 이를 우회하려고 개발자들이 코드에 TLS 검증 무시(InsecureSkipVerify) 옵션을 넣는 순간, 사내망의 모든 암호화 통신은 해커의 중간자 공격 앞마당으로 전락한다. 사내망이라도 반드시 사내 전용 사설 CA(Private CA) 인프라를 정식으로 올리고, 임직원 PC에 그 Root 도장을 그룹 정책(GPO)으로 배포해 정상적인 신뢰 사슬을 태워야 한다.
📢 섹션 요약 비유: 나 스스로 "난 착한 사람이야"라고 내 명함에 직접 쓴 글씨(자가 서명 인증서)는 세상 아무도 믿어주지 않습니다. 억지로 이 명함을 믿게 시스템(보안 검증 끄기)을 고치면, 동네 도둑놈이 "나도 착한 사람이야"라며 내민 명함까지 몽땅 다 믿어버리는 끔찍한 바보 경비원이 탄생합니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	공개키 직접 교환 (PKI 부재)	X.509 v3 기반 인증서 생태계 적용	개선 효과
정량 (확장성)	서로 아는 서버끼리 1:1로 수동 키 교환 1,000번 수행	전 세계 불특정 다수의 서버와 0.1초 만에 안전 통신	통신 대상 확장 지수 무한대 (글로벌 웹 경제 완성)
정량 (장애 시간)	인증서 엑셀 수동 관리 시 휴먼 에러 만료 셧다운 발생률 높음	ACME 기반 Cert-manager 등 90일 자동 갱신 시스템 결합	인증서 유효기간 누락에 의한 서비스 정지 0분 달성
정성 (데이터 방어)	중간자 공격(MitM) 및 피싱 가짜 사이트 접속 위험 심각	브라우저 단계에서 가짜 도장(서명 불일치) 원천 차단	엔드유저의 피싱 낚시 방어 및 HTTPS 암호화 기밀성 강제 확립

미래 전망 및 진화 방향

PQC (Post-Quantum Cryptography) 양자 내성 암호 적용 X.509: 구글(양자 컴퓨터) 같은 거대 테크 기업이 쇼어 알고리즘을 실용화하는 순간, 현재 전 세계 X.509 인증서에 찍힌 도장의 핵심인 RSA/ECC 암호 수학 공식이 1분 만에 산산조각 난다(Q-Day). 이에 대비해 최근 IETF와 NIST는 양자 컴퓨터도 풀지 못하는 격자 기반 암호(Kyber/ML-KEM 등)를 X.509 서명 알고리즘 자리에 욱여넣는 차세대 PQC 하이브리드 인증서 규격 업그레이드를 피 터지게 진행하고 있다.
Certificate Transparency (CT, 인증서 투명성) 의무화: 옛날엔 해커가 몰래 부패한 CA 직원을 매수해서 '가짜 구글 인증서'를 발급받으면 아무도 모르게 공격이 가능했다. 이를 막기 위해 "세상에 발급되는 모든 인증서는 위변조 불가능한 블록체인 같은 공개 장부(CT Log)에 무조건 박제해야만 브라우저가 인정해 준다"는 규칙이 확립되었다. 덕분에 CA 기관의 타락이나 실수까지 전 세계가 투명하게 감시하는 생태계가 완성되었다.

참고 표준

RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (X.509 v3 핵심 기술 규격 표준)
RFC 8555: Automatic Certificate Management Environment (ACME) - Let's Encrypt를 탄생시킨 자동화 프로토콜

X.509 인증서는 인터넷이라는 거대한 얼굴 없는 사회를 '신뢰가 통용되는 대륙'으로 묶어준 보이지 않는 외교 문서다. 이 샌드위치 구조의 텍스트 조각 안에 담긴 수학적 디지털 서명 하나가, 수조 달러가 오가는 글로벌 전자상거래와 금융을 뒷받침하는 콘크리트 바닥이다.

📢 섹션 요약 비유: 서로 누군지 얼굴도 못 보는 어두운 인터넷 세상에서, 모두가 공통으로 존경하고 믿는 재판장님(Root CA)이 찍어준 특수 인감도장(X.509 서명)이 발명된 덕분에, 인류는 두려움 없이 신용카드 번호와 기밀 데이터를 상대방에게 전송할 수 있는 위대한 전자상거래 시대를 열 수 있었습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
PKI (Public Key Infrastructure)	X.509 인증서를 찍어내고, 보관하고, 검증하고, 폐기하는 거대한 사회적·기술적 인프라 시스템 전체를 아우르는 철학적 이름이다.
SSL / TLS (HTTPS)	X.509 인증서의 가장 거대하고 유명한 소비처로, 클라이언트와 서버가 암호화된 파이프(HTTPS)를 뚫기 직전에 "네가 진짜 구글이냐?"를 심문하는 용도로 인증서를 검증한다.
Root CA (최상위 인증 기관)	신뢰 사슬의 맨 꼭대기에 군림하는 절대 존재로, 그들의 공개키는 전 세계 모든 브라우저(크롬, 사파리, 윈도우)의 배꼽 안에 공장 출고 때부터 박혀서 배포된다.
OCSP Stapling	"이 인증서가 폐기됐나?" 묻기 위해 클라이언트가 보건소(CA)로 뛰어가게 만들지 않고, 서버가 아침에 미리 보건소 도장을 받아와서 클라이언트에게 보여주어 속도를 극대화하는 혁신 융합 기술이다.
SAN (Subject Alternative Name)	X.509 v3 규격 확장의 꽃으로, 구형 버전이 도메인 하나만 담을 수 있었던 족쇄를 부수고 여러 도메인을 한 장의 인증서에 욱여넣어 관리를 혁신적으로 편하게 만든 일등 공신이다.

👶 어린이를 위한 3줄 비유 설명

길에서 누가 "나 경찰이야!"라고 말할 때 경찰 신분증이 없다면 아무도 안 믿어주겠죠? 컴퓨터 세상(인터넷)에서도 "나 네이버야!"라고 외치는 해커들이 엄청 많아요.
그래서 컴퓨터들도 X.509라는 '디지털 전자 신분증'을 검사해요. 이 신분증은 세상 모두가 믿는 '최고 대장님(Root CA)'이 절대 위조할 수 없는 마법의 도장을 쾅 찍어준 진짜 증명서예요.
우리들의 인터넷 브라우저(크롬, 사파리)는 이 신분증과 도장이 진짜인지 눈 깜짝할 새(1밀리초)에 확인해 주고, 진짜일 때만 비밀번호나 은행 카드 번호를 안전하게 넘겨주도록 찰떡같이 지켜준답니다.