Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à NDC 2018 디지털 신원 확인 101
Similaire à NDC 2018 디지털 신원 확인 101 (20)
Plus de tcaesvk
Plus de tcaesvk (8)
NDC 2018 디지털 신원 확인 101
- 1. 디지털 신원 확인 101 ㈜넥슨코리아 데브캣 스튜디오 서버엔진팀 김재석
- 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쪽
- 8. 디지털 신원 지침
- 10. 등록 및 신원 증명 되다 가입자 신청자 자격증명 서비스 공급자 등록 및 신원 증명
- 11. 등록 및 신원 증명 되다 가입자 신청자 자격증명 서비스 공급자 등록 및 신원 증명 인증 수단 등록/발급
- 12. • 신청자 applicant • 자격증명 서비스 공급자 credential service provider • 등록 enrollment • 신원 증명 identity proofing • 인증 수단 authenticator • 발급 issuance • 수명 lifetime
- 14. 디지털 인증 청구자 인증 검증자 자격증명 서비스 공급자 인증 수단/자격증명이 묶임을 확인 되다 가입자
- 15. 디지털 인증 청구자 인증 검증자 자격증명 서비스 공급자 인증 수단/자격증명이 묶임을 확인 특성 되다 가입자
- 16. 디지털 인증 청구자 인증 검증자 자격증명 서비스 공급자 인증 수단/자격증명이 묶임을 확인 특성 되다 가입자 인증 주장 신뢰 당사자
- 17. 디지털 인증 청구자 인증 검증자 자격증명 서비스 공급자 인증 수단/자격증명이 묶임을 확인 특성 되다 가입자 인증 주장 신뢰 당사자 인증된 세션
- 18. • 청구자 claimant • 검증자 verifier • 인증 authenticate • 묶임 bind • 특성 attribute • 주장 assertion • 신뢰 당사자 relying party
- 19. 디지털 신원 모형 되다 가입자 신청자 자격증명 서비스 공급자 등록 및 신원 증명 인증 수단 등록/발급 등록 및 신원 증명 인증 되다 청구자 검증자 인증 수단/자격증명이 묶임을 확인 특성 신뢰 당사자 인증 주장 인증된 세션 디지털 인증
- 20. 인증 및 수명 주기 관리에 집중 • 전체를 다루기에는 분량이 많음 • 사용자 경험에 더 많은 영향 • 기고문을 통해 모범사례·실패사례도 많이 공유되는 분야 • 특히 더 이상 사용하지 말아야 할 낡은 방법도 많은 분야
- 21. 인증 수단 Authenticator 청구자의 신원을 인증하는데 사용하는 청구자가 소지하고 조작하는 무언가
- 22. 인증 수단에서의 요소 • 지식 기반 요소: 가입자가 알고 있는 것 • 소지 기반 요소: 가입자가 갖고 있는 것 • 특성 기반 요소: 가입자를 나타내는 것
- 23. 사용되는 요소의 수에 따라 • 1 종류의 요소만 사용하면 단일 요소 • 2 종류 이상의 요소를 사용하면 다중 요소 • 같은 종류의 요소를 여러 개 쓰는 것은 단일 요소
- 24. 인증 수단의 종류
- 25. 의도를 가지고 구분해서 사용하는 용어 • 비밀 secret • 개인식별번호 personal identification number • 숫자만으로 이루어진 경우 • 통과단어 password • 통과구문 passphrase • 보안을 위해 사용하는 긴 길이의 비밀 • 암호화 encrypted • 암호학적 cryptographic
- 26. • 정보 엔트로피: 불확실성의 정도
- 27. 외워 쓰는 비밀 Memorized Secret
- 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비트 이상의 길이를 갖는 임의로 선택된 소금을 치고 단방향 함수로 해시한 뒤 소금 및 해시를 저장
- 39. 찾아 쓰는 비밀 Look-Up Secret
- 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비트 이상의 길이를 갖는 임의로 선택된 소금을 쳐서 단방향 함수로 해시한 뒤 소금 및 해시를 저장
- 45. 대역 외 장치 Out-of-Band Devices
- 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비트 이하인 경우 실패한 인증 시도 횟수를 효과 적으로 제한하는 매커니즘을 구현해야 함 • 도청과 중간자 공격으로부터 저항을 제공하기 위해서 인가된 암호화 방법을 사용하고 인증되고 보호된 경로를 이용해야 함
- 64. 다중 요소 1회용 비밀번호 장치 Multi-Factor OTP Device
- 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가 중복 사용되었다고 경고할 수 있다.
- 69. 단일요소 암호학 소프트웨어 Single-Factor Cryptographic Software
- 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”: ******************************* $
- 83. 예시 • 공인인증서 • 안전한 저장소에 저장하지 않음 • PIN 로그인 https://opennet.or.kr/1761 ❌ ✔
- 84. 검증 요구 조건 • 검증자가 시도 비표를 생성해 인증 수단에 전송하고 출력으로 키 소유 및 제어를 증명 • 구체적인 암호화 프로토콜에 크게 의존하지만 대체로 서명된 메시지 형태 • 대칭 혹은 비대칭 암호화 키를 갖는데, 변경으로부터 보호돼야 하고 대칭 키의 경우 비인가 공개로부터 또한 보호돼야 한다. • 시도 비표는 길이가 64비트 이상이고 통계적으로 고유하며 인가된 암호화를 사용해야만 한다.
- 85. 다중 요소 암호화 장치 Multi-Factor Cryptographic Device
- 86. 다중 요소 암호화 장치 • 소지 기반 요소: 가입자가 갖고 있는 것 • 보호된 암호화 키로 암호화 작업을 수행하고 사용자 끝점에 직접 연결해서 출력을 제공하는 하드웨어 장치 • 대칭·비대칭 암호화 키를 내장 • 두번째 요소로 활성화시키고 인증 프로토콜을 통해 키 소유 및 제어를 증명 • 구체적인 암호화 프로토콜에 크게 의존하지만 대체로 서명된 메시지를 출력
- 87. 요구 조건 • 단일 요소 암호화 장치와 비슷하지만 작동할 때 • 무작위로 6자리 이상인 10진법 숫자 또는 요구조건을 만족시키는 다는 외워 쓰는 비밀을 입력하거나 • 생체 인식을 사용해야 한다. • 기기 내에서 사용한 생체 인식 자료는 OTP 생성 이후 0으로 채워 파기해야 한다. • 생체 인식에 5회 (표시 공격presentation attack 감지를 구현하면 10회) 연속 실패하면 • 다음 시도까지 적어도 30초 이상 지연시켜야 하며, 계속 실패하면 지수적으로 (1분, 2분, 4분, …) 지연 시간을 늘려야 한다. • 또는, 중지시키고 다른 종류의 생체 인식을 하거나 (얼굴지문) 알고 있는 것을 입력하도록 해야 한다.
- 89. 검증 요구 조건 • 검증자가 시도 비표를 생성해 인증 수단에 전송하고 출력으로 키 소유 및 제어를 증명 • 구체적인 암호화 프로토콜에 크게 의존하지만 대체로 서명된 메시지 형태 • 대칭 혹은 비대칭 암호화 키를 갖는데, 변경으로부터 보호돼야 하고 대칭 키의 경우 비인가 공개로부터 또한 보호돼야 한다. • 시도 비표는 길이가 64비트 이상이고 통계적으로 고유하며 인가된 암호화를 사용해야만 한다.
- 90. 인증 수단에 따른 인증 요소
- 91. 인증 요소로 구분하면 • 지식 기반 요소: 가입자가 알고 있는 것 • 소지 기반 요소: 가입자가 갖고 있는 것 • 특성 기반 요소: 가입자를 나타내는 것 • 없음
- 92. 인증 수단 보증 수준 Authenticator Assurance Level (AAL)
- 93. AAL1: 단일 요소 인증
- 94. AAL2: 다중 요소 인증 (1/2)
- 95. AAL2: 다중 요소 인증 (2/2) +
- 96. AAL3: 하드웨어를 이용한 다중 요소 인증 (1/6)
- 97. AAL3: 하드웨어를 이용한 다중 요소 인증 (2/6) +
- 98. AAL3: 하드웨어를 이용한 다중 요소 인증 (3/6) +
- 99. AAL3: 하드웨어를 이용한 다중 요소 인증 (4/6) 하드웨어만 +
- 100. AAL3: 하드웨어를 이용한 다중 요소 인증 (5/6) 하드웨어만 +
- 101. AAL3: 하드웨어를 이용한 다중 요소 인증 (6/6) 하드웨어만 + +
- 102. 디지털 신원 지침 보증 수준을 결정하는 기준
- 103. 보증 수준 영향의 범주 1 2 3 불편함, 고통, 또는 명성이나 평판 훼손 낮음 보통 높음 재정적 손실이나 기관 책임 낮음 보통 높음 기관 강령이나 공공 이익에 해를 끼침 없음 낮음/보통 높음 민감한 정보의 비인가 공개 없음 낮음/보통 높음 개인 안전 없음 낮음 보통/높음 민·형사상의 법규 위반 없음 낮음/보통 높음 각 보증 수준에 대한 최대 잠재 영향
- 104. IAL: 신원 보증 수준 IAL 설명 1 스스로 주장하는 특성 2 원격으로 신원 증명 3 개인 신상을 증명하고 식별에 쓰이는 특성들이 검증됨
- 105. 신원 보증 수준의 결정
- 106. AAL 설명 1 단일 요소 인증 2 다중 요소 인증 3 하드웨어를 이용한 다중 요소 인증 AAL: 인증 수단 보증 수준
- 107. 인증 수단 보증 수준의 결정
- 108. AAL1 AAL2 AAL3 IAL1: 개인정보 없음 ✔ ✔ ✔ IAL1: 개인정보 있음 ❌ ✔ ✔ IAL2 ❌ ✔ ✔ IAL3 ❌ ✔ ✔ 신원·인증 수단 보증 수준의 허용되는 조합
- 109. 정리 • 외워 쓰는 비밀은 단독으로 쓸 수 없습니다. • 개인 정보가 없는 경우에만 사용 가능 • 다른 인증 수단에 비해 보안 강도도 낮은데 자주 바꾸게 하면 귀찮은 가입자들은 점차 약한 비밀을 사용합니다. • 적절한 인증 수단으로 편의와 보안의 균형을 갖추시기를…….
- 110. Q&A
- 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.