Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

NDC 2018 디지털 신원 확인 101

681 views

Published on

NEXON Developers Conference 2018
2018-04-26T16:30+09:00/PT30M
GB1 Tower B1

Published in: Software
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

NDC 2018 디지털 신원 확인 101

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

×