2. 발표자 소개
2017/현재 서버엔진팀
2016/2017 미공개 프로젝트
2014/2015 마비노기 듀얼
2014/2014 링토스 세계여행
2010/2013 마비노기2: 아레나
2006/2009 마비노기 영웅전
2004/2005 마비노기
2003/2004 프로젝트 T2
2001/2003 오즈
3. NIST SP 800-63
디지털 신원 지침
• 미합중국 국립표준기술연구소
특별 간행물
• 미 연방 정부의 권고안이지만
상업적으로·국제적으로
통용되는 기준
• 3차 개정 (2016)
4. 한국정보통신기술협회
• 정보통신단체표준 (TTAS)
TTAK.KO-12.0247 전자거래 보증 수준별 인증방법 요구사항
• 국제정보통신연합 (ITU) 권고안
X.1254: 개체 인증 보증 프레임워크를 참조
• NIST SP 800-63 1.0.2판 전자 인증 지침 (2006)에 기반
• ISO/IEC 29115:2013 정보 기술 – 보안 기술 – 개체 인증 보증 프레임워크로
국제표준화기구 및 국제전기기술위원회에서 표준화
5. 금융보안원
• 국무총리 소속 금융위원회 주도로 설립된 금융보안전담기구
• 보안연구부 보안기술연구팀에서 지속적으로 NIST 표준을 참고
제목 작성일
미 국립표준기술연구소, 패스워드 관리에 대한 권고사항 2017-09-15
신원정보 관리유형의 변화와 특징 비교 2017-03-07
인증기술 도입을 위한 선정 프로세스 소개 2017-01-26
바이오인증 도입 및 운영 시 보안요구사항 - NIST, 디지털 인증 가이드라인 중심 - 2016-09-23
NIST, ‘디지털 인증 가이드라인(Draft)’의 권고사항(요약) 2016-09-05
6. 짧게 요약하면
• 외워 쓰는 비밀은 해롭습니다.
• 외워 쓰는 비밀을 자주 바꾸게 하면 더 해롭습니다.
7. 디지털 신원 지침
A4 74쪽
등록 및 신원 증명
A4 48쪽
인증 및 수명주기 관리
A4 79쪽
연합 및 주장
A4 49쪽
25. 의도를 가지고 구분해서 사용하는 용어
• 비밀 secret
• 개인식별번호 personal identification number
• 숫자만으로 이루어진 경우
• 통과단어 password
• 통과구문 passphrase
• 보안을 위해 사용하는 긴 길이의 비밀
• 암호화 encrypted
• 암호학적 cryptographic
28. 외워 쓰는 비밀
• 지식 기반 요소: 가입자가 알고 있는 것
• 사용자가 골라 외우는 통과단어·개인식별번호 따위의 비밀
• 공격자가 추측하거나 발견하기 어렵도록 충분히 남모르게 복잡
해야 한다.
29. 요구 사항
• 가입자가 정하는 경우 8자 이상의 길이
• 가입자가 정한 비밀이 과거에 누출로 금지 목록에 포함된 이유로 CSP
또는 검증자가 거절하면, 다른 비밀로 다시 정해야 한다.
• 그 밖에 복잡하게 정할 것을 강요하지 말아야 한다.
• CSP 또는 검증자가 무작위로 정하는 경우 6자 이상의 길이어야
하는데 숫자로만 이루어져도 된다.
30. 검증 요구 사항
• 가입자가 정하는 비밀은 8자 이상의 길이여야 하고 최대 길이도
64자 이상을 허용해야 한다.
• 비밀을 새로 만들거나 바꿀 때 널리 사용되거나, 예측할 수 있거
나, 위협에 노출된 목록과 비교돼야 한다. 다음은 그 일부이다
• 누출된 목록
• 사전 낱말
• 반복되거나 연속된 문자
• 맥락으로 특정할 수 있는 낱말: 서비스의 이름, 사용자이름, 또는 그로
부터 파생된 것
31. 검증 요구 사항
• 가입자가 강한 비밀을 고르도록 비밀-강도계 따위로 안내
• 거절된 비밀을 사소하게 고쳐 만든 약한 비밀을 못 쓰게 하기 위해
https://www.techwyse.com/blog/website-design/remove-website-hack-message/
32. 검증 요구 사항
• 그 밖의 조합 규칙을 강요해서도, 임의로 바꾸도록 강요해서도
안된다.
• 다만, 외운 비밀이 위협에 노출됐다는 증거가 있을 경우 바꾸도록 강제
해야 한다.
❌ ❌
33. 검증 요구 사항
• 인증되지 않은 청구자가 접근할 수 있는 "힌트” 저장 금지
• 가입자가 비밀을 고르는 동안 종류를 특정할 정보를 보여주면
안 된다.
• 첫 애완동물의 이름
• 학교
• 가족
34. 검증 요구 사항
• 외운 비밀을 입력할 때 "붙여넣기" 기능을 허용해 비밀 관리자
등을 이용해 더 강한 비밀을 사용하게 한다.
• 청구자가 비밀을 제대로 입력했는지 확인할 수 있도록 점이나
별표의 나열 대신 선택적으로 비밀을 보여줘야 한다.
• 개별 글자를 치는 동안 잠시 보여주면 휴대 기기에서 유용하다
35. 검증 요구 사항
• 공백을 포함한 모든 출력 가능한 ASCII 글자를 허용하고
유니코드 글자도 허용한다.
• 각 코드포인트는 1개의 길이로 세어야 한다.
• 비밀을 잘라서는 안 된다.
• 오타를 허용하기 위해, 그 결과가 8자 이상인 경우 검증 전에 연속적인
공백문자를 하나의 공백으로 대체할 수도 있다.
36. 검증 요구 사항
• 유니코드 비밀을 받아들일 때에는 정해진 방법으로 정규화해야
한다.
• 비밀을 나타내는 바이트 문자열을 단방향 암호화 하기 전에 이루어져
야 한다.
• 가입자가 비밀에 유니코드 글자를 사용하면 사용 환경에 따라
생김새가 다르게 보이기도 하고 인증 여부에도 영향을 준다고
고지 받는다.
37. 검증 요구 사항
• CSP (등록) 또는 검증자가 (변경) 만드는 비밀은 인가 받은 난수
비트 생성기를 이용해서 6자 이상 무작위로 발급해야 한다.
38. 검증 요구 사항
• 실패한 인증 시도 횟수를 효과적으로 제한하는 매커니즘을 구
현해야 함
• 도청과 중간자 공격으로부터 저항을 제공하기 위해서 인가된
암호화 방법을 사용하고 인증되고 보호된 경로를 이용해야 함
• 오프라인 공격이 힘들게 저장
• 32비트 이상의 길이를 갖는 임의로 선택된 소금을 치고
단방향 함수로 해시한 뒤 소금 및 해시를 저장
40. 찾아 쓰는 비밀
• 소지 기반 요소: 가입자가 갖고 있는 것
• 청구자와 CSP 사이에 공유되는 기록
• 검증자가 표 형식으로 기록의 일부를 청구자에게 요구할 수 있다.
• 일반적으로 다른 인증자를 분실했거나 오작동할 경우의 “복구 키”
41. 요구 사항
• CSP가 인가 받은 무작위 비트 생성기로
20비트 이상의 엔트로피로 생성해서 사용자에게 안전하게
• 직접 전달하거나
• 우편으로 배송하거나
• 온라인의 경우 요구사항을 준수하는 보안 안전한 통신 경로로 배포
• 찾아서 사용한 비밀은 인증이 성공했을 때 가입자가 파기 가능
42. 예시
• 보안카드
• 해당하지 않음
• 반복 사용 = 파기 불가
• 등기필증의 등기필정보
• 현실적으로 재사용이 일어나지 않는다.
https://opennet.or.kr/3570
❌
https://blog.naver.com/heemang0307/220503871080
✔
한번 사용한 비밀번호는 두번 사용할 수 없습니다. 다만
비밀번호 50개를 전부 사용한 경우에는 기존 비밀번호를
재사용할 수 있습니다. http://www.iros.go.kr/pos1/jsp/help2/jsp/002003001002.jsp
43. 검증 요구 사항
• 청구자에게 다음 혹은 특정 (예: 몇 번째) 비밀을 요구하되 주어
진 비밀을 단 한 번만 성공적으로 사용
• 격자의 각 칸은 단 한 번만 사용되어야 한다.
44. 검증 요구 사항
• 엔트로피가 64비트 이하인 경우 실패한 인증 시도 횟수를 효과
적으로 제한하는 매커니즘을 구현해야 함
• 도청과 중간자 공격으로부터 저항을 제공하기 위해서 인가된
암호화 방법을 사용하고 인증되고 보호된 경로를 이용해야 함
• 오프라인 공격이 힘들게 저장
• 엔트로피가 112비트 이상인 경우 인가된 단방향 함수로 해시해 저장
• 엔트로피가 112비트 미만인 경우 32비트 이상의 길이를 갖는 임의로
선택된 소금을 쳐서 단방향 함수로 해시한 뒤 소금 및 해시를 저장
46. 대역 외 장치
• 소지 기반 요소: 가입자가 갖고 있는 것
• 독립된 통신 경로를 이용하고
• 특정한 장비를 소지하고 조작하는지를 검증
47. 요구 조건
• 음성 인터넷 프로토콜(VOIP)·전자메일처럼 장치의 소유를 증명
하지 못하는 방법은 사용되어서는 안 된다
48. 요구 조건
• 공중 교환 전화망(PSTN)을 사용할 경우
• 장치를 고유하게 식별하는 SIM카드 혹은 이와 동등한 장치를 이용해서
인증한다. SMS·음성의 형태로 전달하는 경우에만 사용돼야 한다.
• 그 외의 경우
• 인가된 암호화 방법을 사용하고 인증되고 보호되는 경로를 확립해서
증명한다.
• 사용하는 키는 적절히 안전한 저장소에 저장해야 한다.
• 키-체인 저장장치
• 신뢰 플랫폼 모듈(TPM)
• 신뢰 실행환경(TEE)
49. 주 통신 경로와 묶기
• 보조 통신 경로로 전달받은 비밀을 주 통신 경로로 전송
주 통신
경로
청구자
검증자
보조 통신 경로
입력
50. 주 통신 경로와 묶기
• 주 통신 경로로 전달받은 비밀을 대역 외 장치로 전송
청구자
검증자
보조 통신 경로
입력
주 통신
경로
51. 주 통신 경로와 묶기
• 주 통신 경로와 대역 외로 전달한 비밀을 대조해 대역 외에서
승인
청구자
검증자
보조 통신 경로
확인
주 통신
경로
52. 장치를 잠글 때
• 소유자가 장치를 잠근 동안 대역 외 장치로 전송된 비밀은
• 내용이 표시되면 안 되지만
• 전송이 됐다는 사실은 표시해야 한다.
53. 검증 요구 조건
• 인증 수단이 보안 응용일 경우
• 푸시 알림을 전송하고
• 인증되고 보호되는 경로 확립을 기다려서
• 인증 수단 식별 키를 검증한다.
• 인증 수단 식별 키 자체를 저장하면 안 되고
인가된 해시 함수나 식별 키의 소유 증명같은 검증 방법을 이용한다.
• 인증 수단으로 공중 교환 전화망(PSTN)을 사용할 경우
• 전화 번호와 장비가 일치하는지 검증한다.
54. 검증 요구 조건
• 검증해서 인증이 된 인증 수단으로만 비밀을 전송한다.
• 대역 외 장치를 주 통신 경로와 묶는 모든 방법에 인증은 10분
이내에 완료되지 않으면 무효로 간주한다.
• 재생 공격replay attack이 힘들도록 비밀은 단 한 번만 사용된다.
55. 검증 요구 조건
• 인증에 사용될 비밀은 인가받은 무작위 비트 생성기로 20비트
이상의 엔트로피로 생성해야 한다.
• 엔트로피가 64비트 이하인 경우 실패한 인증 시도 횟수를 효과
적으로 제한하는 매커니즘을 구현해야 함
56. 단일 요소
1회용 비밀번호 장치
Single-Factor One-Time Password (OTP) Device
57. 단일 요소 1회용 비밀번호 장치
• 소지 기반 요소: 가입자가 갖고 있는 것
• 1회용 비밀번호OTP 하드웨어 장치 혹은 소프트웨어 기반 생성기
• 찾아 쓰는 비밀과 달리 시간이나 계수counter 기반으로 비밀을 생성
• 암호학적으로
• 인증자 및 검증자가 독립적으로
• 검증자에게 전송할 때 장치에 표시된 OTP를 수동으로 작동시켜
소지해서 제어하고 있음을 증명
58. 요구 조건
• 비밀 키와 알고리듬에 112비트 이상의 보안 강도를 제공한다.
• 소프트웨어 기반 OTP 생성기는 비밀 키를 여러 장비에 옮기기
어려워야 한다.
59. 요구 조건
• 비표nonce는 충분히 길어서 매 작동에 사용할 때 유일해야 한다.
• 주어진 비표와 관련된 OTP 값은 단 한 번 사용되어야 한다.
• 인가된 블록 암호 혹은 해시함수로
비밀 키와 비표를 안전하게 결합해서 OTP 출력을 생성한다.
• 10진수로 6자리 (대략 20비트의 엔트로피) 이상으로 자를 수 있다.
• 실시간 시계 기반 OTP에서 비표는 늦어도 2분마다 바꿔야 한다.
60. 예시
• 하드웨어 장치
• RFC 6238 TOTP: 시간-기반 1회용 비밀번호 알고리듬
https://safenet.gemalto.com/multi-factor-authentication/authenticators/oath-tokens/
61. 검증 요구 조건
• 인증 수단과 동일한 방법으로 OTP를 생성
• 인증 수단의 비밀 키는 대칭으로 검증자에도 존재하고
침해로부터 강하게 보호되어야 한다.
62. 검증 요구 조건
• 인증 수단을 가입자 계정에 연결할 때 검증자나 관련 CSP는
비밀을 생성하고 교환해서 가입자가 비밀을 획득할 때
인가된 암호화 방법을 사용해야 한다.
https://docs.pulsesecure.net/WebHelp/Content/PCS/PCS_AdminGuide_8.2/Using%20Google%20Authenticator%20Application%20to%20Register%20to%20a%20TOTP%20Server.htm
63. 검증 요구 조건
• 엔트로피가 64비트 이하인 경우 실패한 인증 시도 횟수를 효과
적으로 제한하는 매커니즘을 구현해야 함
• 도청과 중간자 공격으로부터 저항을 제공하기 위해서 인가된
암호화 방법을 사용하고 인증되고 보호된 경로를 이용해야 함
65. 다중 요소 1회용 비밀번호 장치
• 소지 기반 요소: 가입자가 갖고 있는 것
• 1회용 비밀번호OTP 하드웨어 장치 혹은 소프트웨어 기반 생성기
• 검증자에게 전송할 때 장치에 표시된 OTP를
가입자가 갖고 있는 것이나 가입자를 나타내는 것으로 작동해
소지해서 제어하고 있음을 증명
• 지식 기반 요소: 가입자가 알고 있는 것 (예: 일체형 입력 패드)
• 특성 기반 요소: 가입자를 나타내는 것 (예: 생체 인식 장치)
66. 요구 조건
• 단일 요소 OTP 장치와 비슷하지만 OTP를 얻으려면
• 비밀을 외워서 입력하거나
• 생체 인식을 사용해야 한다.
• 기기 내에서 사용한 생체 인식 자료는 OTP 생성 이후 0으로 채워 파기해야 한다.
• 생체 인식에 5회 (표시 공격presentation attack 감지를 구현하면 10회)
연속 실패하면
• 다음 시도까지 적어도 30초 이상 지연시켜야 하며,
계속 실패하면 지수적으로 (1분, 2분, 4분, …) 지연 시간을 늘려야 한다.
• 또는, 중지시키고 다른 종류의 생체 인식을 하거나 (얼굴지문)
알고 있는 것을 입력하도록 해야 한다.
67. 예시
• 하드웨어 장치
• PIN·생체 인식을 요구하는
휴대전화 소프트웨어
http://www.deepnetsecurity.com/authenticators/one-time-password/safeid/
https://play.google.com/store/apps/details?id=securecomputing.devices.android.controller
68. 검증 요구 조건
• 인증 수단이 다중 요소 장치라는 신뢰할 수 있는 근거가 없다면
장치를 단일 요소 장치로 취급해야 한다.
• 재생 공격이 힘들게 비표nonce의 유효 시간동안 OTP는 단 한 번
허용한다. 인증이 OTP의 중복 사용으로 거부되면 기존 세션에
OTP가 중복 사용되었다고 경고할 수 있다.
70. 단일요소 암호학 소프트웨어
• 소지 기반 요소: 가입자가 갖고 있는 것
• 디스크 혹은 다른 “소프트” 매체에 저장된 암호학적 키
• 소프트웨어를 사용해서 키 소유 및 제어를 증명
• 구체적인 암호화 프로토콜에 크게 의존하지만
대체로 서명된 메시지를 출력
71. 요구 조건
• 인증 수단에 고유한 하나 이상의 비밀키를 캡슐화해서
응용에서 사용할 수 있는 적절히 안전한 저장소 저장해야 한다.
• 키-체인 저장장치
• 신뢰 플랫폼 모듈(TPM)
• 신뢰 실행환경(TEE)
• 장치의 소프트웨어 구성 요소가 접근을 요청할 때만 키에 접근하게
제한해야 한다.
• 비인가 공개unauthorized disclosure가 일어나기 힘들도록
• 키를 여러 장치에 복제하는 것은 어렵고, 허용해서도 안 된다.
72. 예시
• 클라이언트 인증서
Using username “username”
Authenticating with public key “ecdsa-key-20180426”
$
73. 검증 요구 조건
• 검증자가 시도 비표를 생성해 인증 수단에 전송하고 출력으로
키 소유 및 제어를 증명
• 구체적인 암호화 프로토콜에 크게 의존하지만
대체로 서명된 메시지 형태
• 대칭 혹은 비대칭 암호화 키를 갖는데, 변경으로부터 보호돼야
하고 대칭 키의 경우 비인가 공개로부터 또한 보호돼야 한다.
• 시도 비표는 길이가 64비트 이상이고 통계적으로 고유하며
인가된 암호화를 사용해야만 한다.
74. 단일 요소 암호화 장치
Single-Factor Cryptographic Device
75. 단일 요소 암호화 장치
• 소지 기반 요소: 가입자가 갖고 있는 것
• 보호된 암호화 키로 암호화 작업을 수행하고
사용자 끝점에 직접 연결해서 출력을 제공하는 하드웨어 장치
• 대칭·비대칭 암호화 키를 내장
• 인증 프로토콜을 통해 키 소유 및 제어를 증명
• 구체적인 암호화 프로토콜에 크게 의존하지만
대체로 서명된 메시지를 출력
76. 요구 조건
• 비밀키는 장치에 유일하고 장치로부터 꺼낼 수 없다.
• 비밀 키와 알고리듬의 보안강도는 112비트 이상이고
시도 비표는 64비트 이상의 길이로 인가된 암호화를 사용한다.
• 연결된 끝점이 침해됐을 때 의도하지 않게 작동하지 않도록
물리적 입력이 있을 때만 동작해야 한다.
78. 검증 요구 조건
• 검증자가 시도 비표를 생성해 인증 수단에 전송하고 출력으로
키 소유 및 제어를 증명
• 구체적인 암호화 프로토콜에 크게 의존하지만
대체로 서명된 메시지 형태
• 대칭 혹은 비대칭 암호화 키를 갖는데, 변경으로부터 보호돼야
하고 대칭 키의 경우 비인가 공개로부터 또한 보호돼야 한다.
• 시도 비표는 길이가 64비트 이상이고 통계적으로 고유하며
인가된 암호화를 사용해야만 한다.
79. 다중 요소 암호화 소프트웨어
Multi-Factor Cryptographic Software
80. 다중 요소 암호화 소프트웨어
• 소지 기반 요소: 가입자가 갖고 있는 것
• 디스크 혹은 다른 “소프트” 매체에 저장된 암호학적 키
• 두번째 요소로 활성화시키고
소프트웨어를 사용해서 키 소유 및 제어를 증명
• 구체적인 암호화 프로토콜에 크게 의존하지만
대체로 서명된 메시지를 출력
81. 요구 조건
• 단일 요소 암호화 소프트웨어와 비슷하지만 작동할 때
• 무작위로 6자리 이상인 10진법 숫자 또는
요구조건을 만족시키는 다는 외워 쓰는 비밀을 입력하거나
• 생체 인식을 사용해야 한다.
• 기기 내에서 사용한 생체 인식 자료는 OTP 생성 이후 0으로 채워 파기해야 한다.
• 생체 인식에 5회 (표시 공격presentation attack 감지를 구현하면 10회) 연
속 실패하면
• 다음 시도까지 적어도 30초 이상 지연시켜야 하며,
계속 실패하면 지수적으로 (1분, 2분, 4분, …) 지연 시간을 늘려야 한다.
• 또는, 중지시키고 다른 종류의 생체 인식을 하거나 (얼굴지문)
알고 있는 것을 입력하도록 해야 한다.
82. 예시
• 클라이언트 인증서
• 통과구문으로 보호된
Using username “username”
Authenticating with public key “ecdsa-key-20180426”
Passphrase for key “ecdsa-key-20180426”: *******************************
$
84. 검증 요구 조건
• 검증자가 시도 비표를 생성해 인증 수단에 전송하고 출력으로
키 소유 및 제어를 증명
• 구체적인 암호화 프로토콜에 크게 의존하지만
대체로 서명된 메시지 형태
• 대칭 혹은 비대칭 암호화 키를 갖는데, 변경으로부터 보호돼야
하고 대칭 키의 경우 비인가 공개로부터 또한 보호돼야 한다.
• 시도 비표는 길이가 64비트 이상이고 통계적으로 고유하며
인가된 암호화를 사용해야만 한다.
85. 다중 요소 암호화 장치
Multi-Factor Cryptographic Device
86. 다중 요소 암호화 장치
• 소지 기반 요소: 가입자가 갖고 있는 것
• 보호된 암호화 키로 암호화 작업을 수행하고
사용자 끝점에 직접 연결해서 출력을 제공하는 하드웨어 장치
• 대칭·비대칭 암호화 키를 내장
• 두번째 요소로 활성화시키고
인증 프로토콜을 통해 키 소유 및 제어를 증명
• 구체적인 암호화 프로토콜에 크게 의존하지만
대체로 서명된 메시지를 출력
87. 요구 조건
• 단일 요소 암호화 장치와 비슷하지만 작동할 때
• 무작위로 6자리 이상인 10진법 숫자 또는
요구조건을 만족시키는 다는 외워 쓰는 비밀을 입력하거나
• 생체 인식을 사용해야 한다.
• 기기 내에서 사용한 생체 인식 자료는 OTP 생성 이후 0으로 채워 파기해야 한다.
• 생체 인식에 5회 (표시 공격presentation attack 감지를 구현하면 10회)
연속 실패하면
• 다음 시도까지 적어도 30초 이상 지연시켜야 하며,
계속 실패하면 지수적으로 (1분, 2분, 4분, …) 지연 시간을 늘려야 한다.
• 또는, 중지시키고 다른 종류의 생체 인식을 하거나 (얼굴지문)
알고 있는 것을 입력하도록 해야 한다.
89. 검증 요구 조건
• 검증자가 시도 비표를 생성해 인증 수단에 전송하고 출력으로
키 소유 및 제어를 증명
• 구체적인 암호화 프로토콜에 크게 의존하지만
대체로 서명된 메시지 형태
• 대칭 혹은 비대칭 암호화 키를 갖는데, 변경으로부터 보호돼야
하고 대칭 키의 경우 비인가 공개로부터 또한 보호돼야 한다.
• 시도 비표는 길이가 64비트 이상이고 통계적으로 고유하며
인가된 암호화를 사용해야만 한다.
103. 보증 수준
영향의 범주 1 2 3
불편함, 고통, 또는 명성이나 평판 훼손 낮음 보통 높음
재정적 손실이나 기관 책임 낮음 보통 높음
기관 강령이나 공공 이익에 해를 끼침 없음 낮음/보통 높음
민감한 정보의 비인가 공개 없음 낮음/보통 높음
개인 안전 없음 낮음 보통/높음
민·형사상의 법규 위반 없음 낮음/보통 높음
각 보증 수준에 대한
최대 잠재 영향
104. IAL: 신원 보증 수준
IAL 설명
1 스스로 주장하는 특성
2 원격으로 신원 증명
3 개인 신상을 증명하고 식별에 쓰이는 특성들이 검증됨
109. 정리
• 외워 쓰는 비밀은 단독으로 쓸 수 없습니다.
• 개인 정보가 없는 경우에만 사용 가능
• 다른 인증 수단에 비해 보안 강도도 낮은데 자주 바꾸게 하면
귀찮은 가입자들은 점차 약한 비밀을 사용합니다.
• 적절한 인증 수단으로 편의와 보안의 균형을 갖추시기를…….
111. 112비트의 최소 보안 강도는
TDEA(Triple DES) 때문인가요? (1/2)
• NIST SP 800-131A 최신판이 지정한 최소값이 112비트입니다.
• 블록 암호 알고리듬을 사용한 암호화·복호화
• 디지털 서명
• 무작위 비트 생성
• Diffie-Hellman 및 MQV를 사용하는 키 합의
• RSA를 사용하는 키 합의 및 키 전송
• 키 싸기
• 암호학적 키로부터 추가 키를 유도하기
• 해시 함수
• 메시지 인증 코드 (MAC)
112. 112비트의 최소 보안 강도는
TDEA(Triple DES) 때문인가요? (2/2)
• NIST SP 800-131A 권고에서 TDEA는 다음에서 언급됩니다.
• 블록 암호 알고리듬을 이용한 암호화·복호화
• 키 싸기·풀기
• CMAC 기반의 키 유도 함수
• CMAC
• 2016.01.01. 이후로
• 2 키가 다른 TDEA는 과거에 만든 낡은 자료의 복원에만 허용하고
• 3 키가 다른 TDEA는 새로 만들 때도 아직 사용할 수 있습니다.
113. 읽을 거리
제목 작성자 작성일
사용자 인증 개관 Jim Fenton 2018.05.02.
사용자 인증을 쓸 만하게 만들기 Jim Fenton 2018.01.03.
NIST 800-63 지침과 FIDO 인증 FIDO 연합 2017.09.21.
비밀 지침: 접근법을 간단하게 영국 국가사이버안보센터 2016.08.08.
더 나은 비밀 요구사항으로 Jim Fenton 2016.08.02.
강제 비밀 변경에 대해 다시 생각해야 할 때 Lorrie Cranor, 연방거래위원회 2016.05.02.