사전 인증
개념

인증

gabury1

인증은 누군가 내세운 주장이 맞는지 확인하는 일입니다. 확인하는 쪽이 보는 것은 그 주장을 뒷받침하려고 내민 증거뿐입니다. 주장을 받는 단계와 증거를 확인하는 단계로 나뉩니다.

상세

아파트 현관에서 누가 관리사무소에서 왔다고 말합니다. 그 말만으로는 알 수 없으니 사원증을 보여 달라고 합니다.

인증(authentication)은 어떤 시스템 개체나 시스템 자원이 특정 속성값을 갖는다는 주장을 검증하는 과정입니다. RFC(Request for Comments) 4949 는 이 낱말을 그렇게 정의합니다. 검증 대상은 주장이지 개체 자체가 아닙니다.

보안 서비스는 흔히 사용자 신원의 인증에 기댑니다. 다만 인증이 다루는 속성이 신원뿐인 것은 아닙니다. 시스템이 인식하는 어떤 종류의 속성이든 인증의 대상이 될 수 있습니다. 주장하는 쪽도 하나가 아닙니다. 주체가 자기에 대해 주장하기도 합니다. 로그인 자리에서 사용자가 자기 신원을 내세우는 것이 그런 경우입니다. 다른 시스템 개체가 어떤 주체나 객체를 대신해 주장하기도 합니다. 어떤 데이터 객체가 특정 원본에서 나왔다는 주장, 또는 특정 보안 등급으로 분류된다는 주장이 그런 경우입니다.

인증 과정은 두 단계로 이루어집니다. 식별 단계는 주장하는 속성값을 인증 서브시스템에 제시하는 단계입니다. 사용자 식별자가 그런 값입니다. 검증 단계는 인증 정보를 제시하거나 생성하는 단계입니다. 그 인증 정보는 속성과 그 속성이 주장된 대상 사이의 결합을 증명하는 증거로 작동합니다. 개인 키로 서명한 값이 그런 증거입니다. 그 증거로 결합이 확인되면 검증하는 쪽은 주장을 받아들입니다.

sequenceDiagram
    participant C as 주장하는 쪽
    participant V as 검증하는 쪽
    C->>V: 식별 단계 · 주장하는 속성값을 제시
    C->>V: 검증 단계 · 결합을 증명하는 인증 정보를 제시
    V-->>C: 결합이 확인되면 주장을 받아들임

배경

온라인 서비스는 상대를 눈으로 보지 못합니다. 요청에 실려 오는 것은 "나는 누구다" 라는 주장뿐입니다. 그 주장을 그대로 받아들이면 이름을 빌린 요청과 진짜 요청이 구별되지 않습니다. 주장을 내세우는 일과 그 주장을 받아들일지 정하는 일을 갈라놓아야 했던 이유가 여기 있습니다.

미국 국립표준기술연구소(NIST, National Institute of Standards and Technology)의 디지털 신원 지침은 갈라진 자리마다 이름을 붙여 뒀습니다. 주장자는 인증을 받을 자격이 있다고 주장하는 주체입니다. 검증자는 인증 프로토콜을 써서 주장자가 하나 이상의 인증 수단을 소지하고 통제한다는 것을 확인합니다. 그 확인으로 주장자의 신원을 확정합니다. 검증자는 인증 수단이 가입자 계정에 결합되어 있는지 확인해야 합니다. 그 계정이 활성 상태인지도 확인해야 합니다. 가입자는 신원 증명과 등록 절차를 마쳤거나 온라인 서비스에 인증을 마친 주체입니다.

성공한 인증 과정은 주장자가 가입자의 신원에 결합된 유효한 인증 수단 하나 이상을 소지하고 통제한다는 것을 보입니다. 그 결과로 의존 당사자는 주장자가 스스로 말하는 그 사람이라는 것을 일정한 보증 수준까지 신뢰할 수 있습니다.

flowchart TD
    C["주장자"] -->|인증 프로토콜| V["검증자"]
    V -->|결합과 활성 여부 확인| S["가입자 계정"]
    V -->|보증 수준| RP["의존 당사자"]

갈래

무엇을 근거로 주장을 검증하느냐가 축입니다. NIST SP(Special Publication, 특별 간행물) 800-63B 는 인증, 인증 수단 결합, 세션 관리가 한 가지 이상의 비밀을 소지하고 있다는 증명에 기반한다고 적습니다.

아는 것

비밀번호는 가입자가 고르고 외우거나 기록해 두는 비밀값입니다. 숫자로만 된 것은 개인 식별 번호라고 부릅니다. 공격자가 맞는 비밀값을 추측하거나 알아내는 것이 현실적으로 어려울 만큼 실효 강도와 비밀성이 충분해야 합니다. SP 800-63B 는 비밀번호를 "something you know", 곧 아는 것이라고 적습니다.

가진 것

조회 비밀값의 대표적인 쓰임은 일회용 복구 코드입니다. 다른 인증 수단을 잃거나 그것이 고장 났을 때 씁니다. SP 800-63B 는 조회 비밀값을 "something you have", 곧 가진 것이라고 적습니다.

그 자신인 것

세 번째 갈래는 "something you are", 곧 그 자신인 것입니다. 근거가 되는 것은 생체 특징입니다. 생체 인식은 생물학적 특징과 행동적 특징으로 개인을 자동 인식하는 것입니다. 지문, 음성 패턴, 얼굴 특징, 타자 패턴, 스마트폰을 쥔 각도, 화면 압력, 타자 속도, 마우스 움직임, 걸음걸이가 그런 특징입니다.

생체 비교는 카메라나 지문 판독기 같은 생체 센서의 측정값에 기반합니다. 이 측정값은 잡음과 제시 편차의 영향을 받습니다. 그래서 측정된 생체값과 비교 기준값 사이의 차이를 보고 수용 임계값을 정해야 합니다.

다요소

한 인증 수단이 두 갈래에 걸치기도 합니다. 다요소 일회용 비밀번호 장치가 그렇습니다. 일회용 비밀번호(One-Time Passcode, OTP)는 인증 수단에 표시됩니다. 사용자가 그것을 손으로 입력해 검증자에게 전달합니다.

이 장치 자체는 "가진 것" 입니다. 다만 "아는 것" 이나 "그 자신인 것" 중 하나로 활성화됩니다. 단일 요소 일회용 비밀번호 장치와 갈리는 자리가 여기입니다. 다요소 쪽은 활성화 요소의 제시와 검증을 거쳐야 인증 수단에서 일회용 비밀번호를 얻을 수 있습니다. 활성화 요소는 비밀번호 또는 생체 특징입니다.

예시

HTTP

RFC 9110 은 HTTP(HyperText Transfer Protocol) 응답의 WWW-Authenticate 헤더 필드가 대상 자원에 적용되는 인증 스킴과 매개변수를 알린다고 적습니다. 401(Unauthorized) 응답을 만드는 서버는 최소한 하나의 챌린지를 담은 이 필드를 반드시 보내야 합니다. 다른 응답 메시지에서도 이 필드를 만들 수 있습니다. 크리덴셜을 내거나 다른 크리덴셜을 내면 응답이 달라질 수 있다는 것을 알리는 용도입니다.

WWW-Authenticate: Basic realm="simple", Newauth realm="apps",
                 type=1, title="Login to \"apps\""

이 한 줄은 챌린지 두 개를 담습니다. realm 값이 simple 인 Basic 스킴, realm 값이 apps 인 Newauth 스킴입니다. 매개변수 type 과 title 도 함께 실려 있습니다.

반대 방향은 Authorization 헤더 필드입니다. 사용자 에이전트가 자기를 오리진 서버에 인증시키는 자리입니다. 값은 요청 대상 자원의 realm 에 대한 사용자 에이전트의 인증 정보를 담은 크리덴셜입니다. 대개 401 응답을 받은 뒤에 보냅니다. 반드시 그런 것은 아닙니다.

WebAuthn

W3C(World Wide Web Consortium)의 웹 인증 명세는 후보 크리덴셜을 좁힐 단서가 없을 때의 인증 코드를 이렇게 적어 뒀습니다.

JavaScript
if (!window.PublicKeyCredential) { /* Client not capable. Handle error. */ }

// credentialId is generated by the authenticator and is an opaque random byte array
var credentialId = new Uint8Array([183, 148, 245 /* more random bytes previously generated by the authenticator */]);
var options = {
  // The challenge is produced by the server; see the Security Considerations
  challenge: new Uint8Array([4,101,15 /* 29 more random bytes generated by the server */]),
  timeout: 300000,  // 5 minutes
  allowCredentials: [{ type: "public-key", id: credentialId }]
};

navigator.credentials.get({ "publicKey": options })
    .then(function (assertion) {
    // Send assertion to server for verification
}).catch(function (err) {
    // No acceptable credential or user refused consent. Handle appropriately.
});

challenge 는 서버가 만든 무작위 바이트열입니다. credentialId 는 인증 수단이 만든 불투명한 무작위 바이트 배열입니다. timeout 값 300000 은 5분입니다. allowCredentials 에는 타입 public-key 와 그 credentialId 를 넣습니다. 호출이 성공하면 어서션을 받습니다. 그것을 서버로 보내 검증합니다.

커버로스

RFC 4120 은 인증 교환을 메시지 정의로 적어 뒀습니다. 요청은 AS-REQ, 응답은 AS-REP 입니다.

AS-REQ          ::= [APPLICATION 10] KDC-REQ
AS-REP          ::= [APPLICATION 11] KDC-REP

KDC-REQ         ::= SEQUENCE {
        pvno            [1] INTEGER (5) ,
        msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
        padata          [3] SEQUENCE OF PA-DATA OPTIONAL,
        req-body        [4] KDC-REQ-BODY
}

msg-type 값 10 은 AS-REQ, 12 는 TGS-REQ 를 가리킵니다. 같은 KDC-REQ 구조를 두 교환이 나눠 씁니다. 요청 본문 KDC-REQ-BODY 의 cname 은 AS-REQ 에서만 쓰입니다. realm 은 서버의 realm 입니다. AS-REQ 에서는 클라이언트의 realm 이기도 합니다. till, nonce, etype 도 같은 본문에 실립니다. etype 은 선호 순서대로 나열한 암호화 타입입니다. 응답 KDC-REP 는 crealm, cname, ticket, enc-part 를 담습니다.

PAM

리눅스 PAM(Pluggable Authentication Modules)은 인증을 함수 하나로 노출합니다.

C
#include <security/pam_appl.h>

int pam_authenticate(pam_handle_t *pamh, int flags);

사용자는 인증 서비스에 따라 인증 토큰을 제시해야 합니다. 보통 비밀번호입니다. 지문일 수도 있습니다. 서비스 모듈은 대화 메커니즘을 통해 사용자에게 사용자 이름 입력을 요청할 수 있습니다. 인증된 사용자 이름은 PAM_USER 항목에 들어갑니다. pam_get_item(3) 으로 꺼냅니다.

판정은 반환값으로 나옵니다. PAM_SUCCESS 는 인증 성공입니다. PAM_AUTH_ERR 는 인증되지 않았다는 뜻입니다. PAM_USER_UNKNOWN 은 인증 서비스가 모르는 사용자입니다. PAM_MAXTRIES 는 모듈 하나 이상이 시도 한도에 닿았다는 뜻이라 다시 시도하지 않습니다. PAM_AUTHINFO_UNAVAIL 은 모듈이 인증 정보에 접근하지 못한 경우입니다. 네트워크나 하드웨어 장애 때문일 수 있습니다.

관련 항목

인증 정보로 쓰이는 증거

크리덴셜 · 인증 수단 · 인증 토큰 · 챌린지 · realm · 논스 · 티켓 · 어서션 · 일회용 비밀번호 · 조회 비밀값 · 생체 인식 · 개인 키 · 공개 키 · 전자 서명

인증을 정의하는 표준과 기구

NIST · W3C · RFC 4949

인증을 실제로 구현한 프로토콜과 인프라

HTTP 인증 · WWW-Authenticate · Authorization · HTTP 401 · RFC 9110 · HTTP · WebAuthn · 커버로스 · RFC 4120 · PAM · Linux · TLS · 네트워크 · 메시지

인증에서 나뉘는 역할과 주체

주장자 · 검증자 · 가입자 · 신청자 · 크리덴셜 서비스 공급자 · 신원 공급자 · 의존 당사자 · 사용자 에이전트 · 오리진 서버

인증이 거치는 처리 단계

검증 · 신원 증명 · 로그인 · 인가 · 접근 제어 · 세션 · 쿠키 · 세션 관리

인증을 확장하는 방식

다요소 인증 · 싱글 사인온 · OpenID Connect

인증의 신뢰도에 관여하는 요소

보증 수준 · 비밀번호 해싱 · 크리덴셜 스터핑

인증 판정을 나타내는 PAM 반환값

PAM_SUCCESS · PAM_AUTH_ERR · PAM_USER_UNKNOWN · PAM_MAXTRIES · PAM_AUTHINFO_UNAVAIL · PAM_CRED_INSUFFICIENT · PAM_ABORT

다른 이름: authentication · authn