CHIPMAKER

1. TLS Handshake Flow

Full Handshake 과정에 대한 전체 흐름은 아래 그림과 같고, TLS Handshake의 session_id가

empty 상태로 처음부터 모든 cipher suites 협의를 새로하는 경우이다.

(A) Client가 지원하고 선호하는 cipher suits 및 compression 방법들은 서버에게 전달

     구체적인 내용은 RFC5246 정리(2) 참조

• client_version : client TLS 지원 버전
• random : client가 생성한 랜던값
• session_id : Session ID
• cipher_suites : client가 지원하고 선호하는 cipher suites
• compression_methods : client가 지원하는 compression method 들
• extension : 추가정보

(B) (A)에서 client가 전달한 것들 중에 서버가 지원하는 것을 하나 골라 회신

    여기까지가 hellow protocol이고 결국 cipher suites에서 Key Exchange Method를 결정하는 단계이다.

(C) *는 옵션항목이다. 옵션항목들은 서버 및 Client 인증과 관련된 동작이다.

    서버의 인증서를 Client에 전달해야 할 필요 시, 서버의 인증서를 실어서 보낸다.

    (A) ~ (B) hellow protocol에서 결정된 Key Exchange Algorithm에 따라서 여기서 전달되는 인증서 내의

    public key (Certificate Key Type) 사용 목적은 정해져 있고 이는 RFC5246 정리(2) 참조

(D) (C)에서 전달된 메세지만으로는 premaster secret를 결정할 수 없는 경우에 (C)이 후에 즉각적으로 전달된다.

    보통 Key Exchange Algorithm으로 Diffie-Hellman을 사용할 경우에 해당되고,

    Diffie-Hellman 파라미터가 인증서에 포함되어서 전달되면 implicit 방식이라고 해서 이 과정이 생략되지만

    인증서에 존재하지 않는다면 explicit 방식으로 이 과정을 통해서 파라미터를 전달해야 한다.

    이런 관점에서 인증서 전달만으로 불충분할 때 추가 과정이라고 이해하면 된다.

(E) Client에 대한 인증이 필요할 때, 서버가 전달하는 과정이다. 메세지의 Protocol을 이해하기 쉽지 않다.
    서버가 선호하는 Client 서명 방식과 Hash 알고리즘에 대한 정보를 전달하면, 이에 맞게 Client는 응답해야 한다.

    TLS도 상호 인증서 인증을 지원하고 있다고 볼 수 있다.

(F) 여기까지 Cipher Suite에서 Key Exchange Algorithm 및 Authentication까지 완료되었다는

    의미로 이 메세지가 서버에서 클라이언트로 전달된다.

(G) (E) 과정에서 서버가 클라이언트에 클라이언트 인증서를 요청했다면 서버가 요청한 양식에 맞게 회신해야 한다.

(H) 서버 때와 동일하게 클라이언트 인증서만으로 충분한 메세지가 전달되지 않을 경우,

     추가 메세지에 해당한다. 동작 방식과 의미는 서버때와 동일하다.

(I) 이 과정 전까지 전달된 메세지들에 대해서 무결성 검사를 수행하는 단계이다.

   이 과정 전까지 전달된 메세지를 다 모아서 메세지의 무결성 검사를 수행한다고 보면된다.

change_cipher_spec은 TLS Handshake과정에 있는 것은 아니고 TLS Record 과정에서 있다.

이것의 의미는 지금까지 전달된 내용에 동의함을 나타내고, 새로 동의된 cipher suites로

TLS Record과정을 수행하겠다는 것이다.

(J)(K) 완료된 것을 의미하고, TLS Record를 본격으로 전송하기 전에 미리 전송해 보고 문제 없다는

의미로 모두 cipher suites 동의가 완료된 상태이다.

즉 아래 cipher suites 중에 하나가 선택된 것이다.

2. TLS Handshake Flow

Resumed Handshake 과정에 대한 전체 흐름은 아래 그림과 같다.

이 경우에는 TLS Handshake의 session_id가 empty상태가 아니고 client가 session_id가

전에 연결 시 사용하였던 값을 서버에 전달하고 서버가 이에 동의한 경우에 해당한다.

3. 마무리

TLS 1.2에 대해서 부족하지만 세 페이지 걸쳐 살펴보았다.

TLS 세부 동작에 대한 명확한 이해가 있어야 보안취약점도 도출할 것으로 판단된다.

TLS 보안취약점 관련 내용이 TLS 문서상에 있다. 전반적으로 이해를 한 후에 보니

이제 좀 이해가 되는 듯 하다.

1. TLS Handshake Overview

이 페이지에서는 TLS Handshake에 대해서 다루도록 한다.

TLS Handshake과정은 크게 분류하자면

1) 서버와 클라이언트의 Cryptographic alogorithm을 확인하고 선택하는 단계

2) 클라이언트와 서버를 신분을 확인하는 인증단계

1)의 과정은 TLS Record Layer에서 사용될 실제 Security Parameter를 결정하기 위한 과정이고

2)의 과정은 1)의 과정 중에 기밀을 요하는 정보를 주고 받기 위해서 필요한 과정으로 이해가 된다.

2)의 과정에 대표적으로 RSA 알고리즘이 쓰는 것으로 보여진다.

TLS Handshake 과정에 사용되는 메세지 형식에 대해서 살펴본다.

2. TLS Handshake

TLS Handshake 임무를 완수하기 위해서 아래와 같은 메세지들을 상호 교환한다.

2.1. hellow_request

Server단에서 발행하는 것으로 신규 TLS Handshake이 필요함을 알리기 위한 메세지이다.

2.2. client_hellow

Server에 처음 접속할 때 또는 hellow_request을 받았을 때 전송. 아래와 같은 정보를 서버에게 전달한다.

2.3. server_hellow

client_hellow을 받은 서버가 회신해야 할 정보이다.

2.4. Hellow Extensions 는 무엇인가?

정확한 이해는 아니지만 위의 client/server hellow protocol에 extensions라는 항목이 있다.

이 extension에 들어갈 수 있는 추가적인 protocol들이 존재한다.

그 가능한 리스트는 문서 Section 12에 기술되어 있다.

이 문서에서 대표적으로 소개한 extension protocol은 Signature Algorithms 이다.

2.5. certificate 메세지를 보면 Key Exchange Algorithm에 따라서 Default Signature 알고리즘이

정리되어 있다. 이 Default Signature 방식은 extension으로 Client가 변경할 수 있다.

하지만 extension 사용하여 구현 시 주의를 해야 한다.

이 extension에서 지원되는 Signature 알고리즘은 Hash + Signature이다. 아래 지원 가능 항목이다.

• Hash Algorithm
  • none, md5, sha1, sha224, sha256, sha384, sha512
• Signature Algorithm
  • anonymous, rsa, dsa, ecdsa

2.5. certificate (server)

Client나 Server를 인증할 때, Certification이 필요할 경우, 이 Certification 관련 정보를 전달하는 메세지이다.

• certificate_list
  • certification chain 순으로 list를 구성해서 전달한다.
  • X.509v3 certfication format

이 부분은 추가적인 설명이지만, 아래 표는 클라이언트와 서버간에 키 교환 방식과 이 때 인증서를 사용했다면

인증서 내의 공개키는 어떤 역활을 하는지에 대한 것으로 해석하면 맞을 것 같다.

Key Exchange Alg.에서 RSA_PSK를 예로 들면 앞에 RSA는 키 교환 방식을 의미하고 뒤의 PSK는 서명 방식을

의미한다고 보면 아래 표가 이해가 될 것이다.

2.6. server_key_exchange

certificate(server) 메세지가 서버에서 client로 전달된 직 후, 서버에서 client에게 전달하는 메세지이다.

모든 경우에 전달되는 것은 아니고 certificate(server)만으로는 충분히 client에게 정보를 제공할 수 없을 경우

이 메세지가 추가적으로 전달된다.

문서 기준 Ephemeral Diffie-Hellman Key Exchange Algorithm 사용 시, 아래 정보가 추가로 전달된다.

• dh_p
  • prime modulus for Diffie_Hellman operation
• dh_g
  • generator for DH operation
• dh_Ys
  • dh_Ys = (dh_g^x mod dh_p) (x는 서버가 선택한 Private 값)

위의 세 값이 그대로 전달되거나 Client와 Server의 Random값과 서명되어 전달될 수 있다.

2.7. certificate_request

보통은 서버가 인증서를 제공하고 클라이언트가 검증하는 형태가 보통이지만, 이 반대의 경우도 지원할 수 있다.

서버는 클라이언트에게 Certification을 요구할 때 사용하는 메세지이다.

•  certificate_types
  • rsa_sign : RSA Key를 포함하고 있는 인증서
  • dss_sign : DSS Key를 포함하고 있는 인증서
  • rsa_fixed_dh : static DH Key를 포함하고 있는 인증서
  • dss_fixed_dh : static DH Key를 포함하고 있는 인증서
• supported_signature_algorithm
• certificate_authorities

위의 세개의 필드로 구성된 정보를 Client에게 주고 인증서를 요청할 수 있다. 예로 Client에서

제공한 인증서는 certificae_type에 정의된 형태의 인증서 양식이여야 하고,

supported_signature_algorithm에 정의된 서명으로 서명되어 있어야 한다. 라는 형식이다.

2.8. server_hellow_done

이 protocol은 서버에 의해서 Client에 전달되며, 서버는 이제 hellow 관련 protocol 수행은 완료하였다는 의미이다.

2.9. ceritificate (client)

이 메세지는 server_hellow_done 완료 후에 Client가 서버에 보낼 수 있는 첫번째 메세지이다.

이 메세지는 서버가 certificate_request 메세지를 Client로 보낼을 때 서버로 보내진다.

certficate (client) 메세지 형식은 certificate_request 메세지와 호환성을 갖는다.

2.10. client_key_exchange

이 메세지는 certificate(client) 뒤에 이어지는 메시지이고, Client에 의해서 항상 보내지는 메세지이다.

이 메세지가 완료되면 Premaster Secret이 결정되고 아래와 같은 메세지가 전달된다.

• RSA-Encrypted Premaster Secret Message
  • Key agreement와 authentication을 위해 RSA가 사용되었고 48 Byte premaster secret이 생성되었다.
  • 생성된 48 Byte Premaster Secret은 Server의 Certificate Public Key 암호화 되었다.
• Client Diffie-Hellman Public Value
  • Client의 Diffie-Hellman Public Value가 클라이언트 인증서에 포함되어 있지 않다면 전송한다.
  • 즉 Diffie-Hellman Public 값이 인증서에 포함되어 있으면 인증서꺼를 사용하고, 포함되어 있지 않으면 추가로 송출한다. 

2.11. certificate_verify

이 메세지는 certificate (client)에 뒤이어 전송되는 메세지이며, Client 인증서를 정확하게 검증하기 위해 전송되는 메세이다.

• handshake_messages
  • client_hellow 메세지를 시작으로 certificate_verify 메세지 전까지 메세지를 모두 모아서 supported_signature_algorithms 에 기술된 서명 알고리즘으로 검증한다.

2.12. finished

change_cipher_spec 메세지가 전송된 후에 key exchange와 authentication 과정이 성공한 것을 검증하기 위해서 보내지는 메세지이다.

즉 실제 Application Layer의 데이터를 실제 보내기 전에 시험 운행을 하기위한 메세지라고 보면 이해가 쉽다.

3. 마무리

여기까지 대략적으로 TLS Handshake 과정에서 사용되는 메세지에 대해서 살펴보았다.

상세한 구조와 Protocol은 문서를 참조하면 더 정확하게 확인할 수 있다.

1. 소개

TLS는 TLS Record Protocol + TLS Handshake Protocol이다. 

• TLS Record Protocol
  • 상위 Protocol(Application Layer)로부터 데이터를 받아서 클라이언트와 서버간에 협의된 Security 파라미터 기반으로 데이터를 가공하고 전송하는 단계.
• TLS HandShake Procol
  • TLS Record Protocol에서 클라이언트와 서버간의 협의를 통해 정해야할 Security 파라미터들을 교환하고 결정하는 단계

위의 그림은 TLS Record Protocol과 TLS HandShake Protocol을 간략화한 그림이다.

(A), (E) : 이 단계는 좀 이상하긴 한데, 시퀀스 다이어그램을 원하는 형태로 그리기 위해서 넣은 것이다. 별 의미 없다.

(C) ~ (D) : TLS Record Protocol에서 사용할 Security Parameter를 실제 결정하는 단계로 TLS HandShake 단계라고한다.

이 단계에서 서버와 클라이언트 정보 교환은 PlainText 기반으로 진행하기 때문에 암호화되어 있지 않다.

따라서 Wireshark와 같은 툴을 사용하면 이 단계에서 동작을 Monitoring 할 수 있다.

다만 TLS Record Layer에서 사용하는데 공개해서는 안될 정보는 보통 비대칭 암호화를 사용한다.

상세 내용은 TLS HandShake 과정에서 살펴 본다.

(F) : (C) ~(D)단계가 완료되면 TLS Record Layer의 Security Parameter가 모두 결정되고, 암호화 채널이 구성된다.

Secure Channel이라고 하며, 암호화 방식은 대칭키 암호화 방식으로 Secure Channel이 구성된다.

지금까지 계략적으로 살펴본 것이고, 이제 TLS Protocol을 상세하게 살펴보도록 한다.

2. Security Parameters of TLS Record Protocol

TLS Handshake 과정을 통해서 TLS Record Protocol에서 사용하기 위해서 결정되어야 할 Security 파라미터 항목은 다음과 같다.

• connection end
  • client 또는 server : 즉 클라이언트 단인지 서버단인지를 나타낸다.
• RRF (Pseudorandom Function) algorithm
  • 해쉬알고리즘
• bulk encryption algorithm
  • TLS Record block을 암호화할 알고리즘 (대칭키 암호화 알고리즘)
• MAC algorithm
  • TLS Record의 메세지 무결성 검사에 사용될 알고리즘
• compression algorithm
  • TLS Record에 사용된 데이터 암축 방식
• master secret
  • 48 Byte로 대칭키 암호화 알고리즘에 사용될 암호화 키를 만드는데 사용된다.
• client random
  • 32 Byte 값으로 클라이언트가 생성한 값
• server random
  • 32 Byte 값으로 서버가 생성한 값

위에 기술된 Security Parameter가 결정되면 다음과 같은 6개의 항목을 생성한다.

• client write MAC key
• server write MAC key
• client write encryption key
• server write encryption key
• client write IV
• server write IV

사용 예는 client write 파라미터들은 서버 단에서 사용되고 클라이언트로부터 받은 TLS Record를 처리하는데 사용된다.

결론적으로 서버와 클라이언트에서 대칭키 암호화 채널을 구성하기 위해서 필요한 암호화 키 정보와 Initial Vector 및

암호화 채널의 무결성 검증을 위한 MAC Key를 결정하는 것이다.

3. TLS Record Protocol 동작

이제 모든 것을 결정되었다. 이제 서버와 클라이언트는 생성된 6개의 항목을 이용해서 서로 데이터를 주고 받는다. 이 때 각 전송 시에 아래와 같은 정보를 서로 관리하고 있다.

• compression state
  • compression algorithm의 현재 상태
• cipher state
  • encryption algorithm의 현재 상태
• MAC key
  • 현재 전송 상태에서 MAC key
• sequence number
  • 각 연결 상태마다 시퀀스 번호를 부여하고 있다. 2^64 -1 값을 넘을 수 없고, Rolling될 수도 없다.

각 TLS Record 전송 시마다 위의 상태를 서로 Check한다. 만약 변경되거나 정의되지 않은 방식으로 동작할 때는 Erorr로 처리된다.

여기서 sequence number에 주목해야 할 점이 있다.

TLS에서 replay attack이 가능여부에 대한 내용이 stack overflow에 많은 논의 거리이다.

결론적으로 seqeunce number에 의해서 replay attack은 불가능하다고 개인적으로 생각한다.

4. 마무리

정확하게 정리했는지는 확실치 않지만, 적어도 RFC 문서를 읽기 전에 읽으면 이해하는데 도움이 될 것으로 판단된다.

TLS HandShake는 다른 페이지를 이용해서 정리하도록 한다.

1. 소개

OAuth2.0-RFC6749정리 (1)에 추상적으로 살펴본 내용들을 좀 더 구체적으로 살펴 보도록 하겠다.

2. Client Registration & Authentication

OAuth2.0-RFC6749정리 (1)에서 기술한 OAuth2.0 프로토콜을 수행하려면 Client는 다음과 같은 선행 작업이 Authorization Server와 이루어져야 하는 Grant Type이 존재한다. 해당 Grant Type은 Code와 Implicit이다.

1. Client Registration 
   • 아래 그림에서 (A)처럼 Client Information을 Authorization Server로 전달하는데, 이 부분은 표준의 몫은 아니고 구현의 몫이다. 즉 어떤 값을 어떤식으로 전달하는지에 대한 내용은 표준이 아니다.
   • 문서에서는 Credential Client은 client_secret을 Public Client은 redirection_url을 반드시 등록하도록 가이드 하고 있다.
   • 아래 그림에서 (B) 등록에 성공하면 Client Identifier에 해당하는 client_id가 전달된다.
   • client_id는 Authorization Server에서 Client 구분자이며, 유일한 값이며, String형식이다.
2. Client Authentication
   • 등록이 완료되면, Client는 자신의 Password에 해당하는 client_secret를 포함하여 인증단계를 거친다.
   • 인증에 성공하면, 이제 그 이후 Action인 Authorization Grant Request 같은 동작을 수행할 수 있다.
   • Client Authentication은 client_id와 client_secret 기반으로 필요 시 수행한다. 즉 꼭 Client 등록 시에 하는 것이 아니라 refresh token을 재 발급 시에 Client 인증이 필요하다면 수행하는 것처럼 Client 인증이 필요한 곳에서 수행할 수 있다.

아래 예제는 refresh token을 재발급 시, client_id와 client_secret을 Authorization Server로 전송하는 것으로 봐서 Client Authentication이 필요한 부분임을 예상할 수 있다. Client 인증과 User인증을 혼선해서는 안된다.

[example]

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

3. RFC문서 기반 표준 프로토콜

Authorization Grant Type이 크게 4가지를 지원하고 각 Grant Type은 아래 프로토콜을 기반으로 Authorization Server와 통신을 통해서 Access Token을 최종 교환한다. 각 단계별 필요한 파라미터를 정리하였고 세부 설명은 표준 문서를 참조하면 된다.

3.1. Authorization Code Grant

위의 OAuth2.0 표준에서 정의한 파라미터를 Authorization Code Grant Type 기준으로 한번 정리해 보았다.

작아서 잘 안보이기는 하지만 대략적인 예제이다.

(A) ~ (D) : Client를 Authorization Server에 등록하는 절차이다.

(E) : response_type을 code로 설정하면, Authorization Request가 Authorization Code Grant Type이다.

redirect_url은 초기 Client 등록 시 사용한 URL이고, 이를 이용해서 Client의 유효성을 계속 검사할 수 있다.

scope는 Authorization Server와 기 약속된 권한 범위에 해당하는 값을 이용해서 권한 신청을 한다.

state는 현재 Client의 상태 정보를 나타내고 이는 Authorization Server에게 일차적으로 Client가 값을 전달하면, Authorization Server가 응답할 때, 함께 실어보내서 Client는 자신의 state를 확인해서 좀 더 보안성을 높일 수 있는 수단으로 사용할 수 있다.

(F) Resource Owner에게 Authorization을 요청하는 것이고, 이 때 Resource Owner에 대한 Authentication을 수행하는 URL로 이동할 수 있다.

(G) Resource Owner가 Authorization 권한 부여 여부를 통보한다.

(H) Resource Owner가 권한을 부여했다면 Authorization Server는 code를 생성해서 code를 회신한다.

(I) Access Token 요청 시, grant_type은 authorization_code로 주고 (H)에서 받은 code를 동봉한다.

(J) 모든 것이 정상 동작하면, Access Token을 받게 된다.

(K) 전달받은 Access Token의 유효시간 동안 계속적으로 Resource를 요청하는데 사용된다.

3.2. Implicit Grant

(A) ~ (D) : Client 등록 과정은 동일하다.

(E) Implicit Grant Type을 사용하기 위해서는 response_type은 token으로 설정한다. 나머지 의미는 동일하다.

Authorization Code Grant Type 대비 Code를 받는 과정이 없다. Client 검증을 하는 단계가 없는 것이고 Implicit 단계에서는 Client가 제공하는 정보를 이용해서 Client를 Authorization Server에서 검증하고 바로 Access Token을 발행한다. 이에 대한 한가지 예로 Client 등록 시 전달된 정보가 redirect_url 정보가 있었다면 Authorization Request 단계에서 전달된 redirect_url값과 비교해서 동일하면 Client는 유효하다라고 판단하고 Access Token을 발행하는 구현을 할 수 있다. 표준에서 예로 든 것을 기술한 것이다.

(H) Access Token Response가 회신된다.

Authorization Code Grant 대비 단계가 확실히 준 것을 볼 수 있다.

3.3. Resource Owner Password Credentials Grant

앞의 3.1와 3.2에서 살펴 본 Grant Type와 다르게 이 Grant Type은 Client 등록 과정을 수행하지 않는다.

(A) Client는 Resource Owner에게서 받은 Resource Owner Credentials을 이용해서 바로 Access Token을 받을 수 있다.

어떻게 Resource Owner의 Credential을 Client가 받는냐는 표준에서 다룰 대상은 아니고 구현의 몫이다.

또한 Access Token Request 프로토콜이 다른 Grant와는 다르다는 점은 주목해 봐야 한다.

(B) Access Token을 받았다.

(C) ~ (D)는 다른 것과 동일하다.

특징은 Client 등록 과정도 없고, 바로 Access Token Request부터 시작해서 Access Token을 Authorization Server로부터 받을 수 있다.

3.4. Client Credentials Grant

Resource Owner Password Credentials Grant Type과 동일하게 Client 등록 과정을 수행하지 않는다.

(A) Resource Owner Password Credentials Grant와 프로토콜은 거의 동일하다. grant_type은 client_credentials로 줘야 한다. 또한 Resource Owner의 Credentials 정보는 필요없고, Client의 Credentials을 이용해서 Access Token을 요청하는 것을 볼 수 있다. 결국 Client 자신에 한정된 Resource에 접근하고자 할 경우 사용될 것을 예측할 수 있다.

(B) ~ (D) Resource Owner Password Credentials Grant와 동일하다.

4. 마무리

OAuth2.0 표준은 Framework이라는 용어를 사용하고 있다. 표준에서 제시된 것이 어디까지 표준이고 어디까지 구현의 몫인지 판단하기 현재로써는 어렵다. 이해도가 100%인 것 같지는 않다.

지금까지 이해도로는 표준의 범위는 매우 좁은 것 같고, 기본적인 큰 틀만 마련해 놓은 것으로 보인다. 실제 구현도 구현하는 사람의 주관적인 구현이 대부분이다.

결국 Authorization Code Grant Type이 구현의 주를 이루는 것 같다.

1. 소개

OAuth2.0 도입 전의 클라이언트/서버 구현은 일단 Resource에 접근하기 위해서 Resource Server를 통해서

사용자 인증을 거친 후, 인증이 성공되면 이 후 Resource 접근 가능한 구조였다.

각 사용자별로 Resource 접근 시마다 인증 성공 여부를 Check해야 한다. 

OAuth2.0을 도입 시, 어떤 장점이 있고, 단점은 무엇인지 아래 글을 통해서 느껴본다.

1.1. 전통적인 모델의 문제점

• 클라이언트(third-party app.)가 향 후 리소스 재 접근을 위하여 리소스 소유자의 Credential을 저장해야 함.
  • OAuth2.0 : Credential 사용 대신, Access Token을 사용
• 패스워드 인증 방식은 보안에 취약한 부분이 존재, 서버가 이 방식만을 인증 방식으로 사용해야하는 제약
  • OAuth2.0 : code, implict grant type은 클라이언트 등록 절차와 리소스 소유자 인증 절차로 보안강화
• 클라이언트가 광범위한 접근 권한을 획득 (사용자별 또는 리소스별 다른 권한 설정이 어려움)
  • OAuth2.0 : OAuth2.0 Access Token의 scope 구문을 사용하여 제어 가능
• 리소스 소유자의 클라이언트의 권한 회수가 어렵다
  • 리소스 소유자는 언제든지 필요 시, 권한 회수가 가능하다.
• Third-party App.의 보안상 허점으로 리소스 소유자의 PW와 PW로 보호된 모든 데이터가 노출될 수 있다.
  • OAuth2.0 : code, access token 및 refresh token이 노출될 수 있다.
  • OAuth2.0에서 발행한 데이터는 유효 기간이라 노출 시간이 제한적이다. 예) access token의 expires_in

2. OAuth2.0 구성요소 (Role)

1. Resource Owner
   • 리소스의 실제 소유자 또는 리소스 접근을 허용할 수 있는 권한을 가진자 (사람인 경우 end-user라 명명)
2. Resource Server
   • 리소스를 관리 서버
3. Client
   • 리소스 소유자를 대리하여 리소스 접근을 요청하는 자(보통 Third-Party App.)
4. Authorization Server
   • 주 역활은 Access Token 발행 서버
   • Refresh Token 발행 
   • Client 인증 (Authorization Grant Type이 Code 일 경우)

Client와 Resource Owner에 대한 개념은 잘 와 닿지 않지만, RFC문서를 반복해 읽다가 보면 어느정도 개념은 잡을 수 있다. 

3. Abstract OAuth2.0 Flow

(A) Client는 Resource Owner에게 직접 또는 Authorization Server를 통한 간접 방식으로 Authorization을 요청

(B) Authorization Grant를 Resource Owner로부터 받는다. Grant Type의 종류는 크게 4가지로 다음절에서 상세 기술한다.

Client가 요청하거나 Server가 지원하는 Type에 따라 결정된다.

나머지 부분은 이해에 큰 무리가 없어서 생략

참고 : (B)와 (C)는 Authorization Grant Type에 따라 수행 여부가 존재하지 않을 수 있다.

4. Authorization Grant Types

Authorizaton Code, Implicit, Resoure Owner Password Credentials 및 Client Credentials가 있다.

4.1. Authorization Code

그림 1.을 Authorization Grant Type이 Authorization Code 관점으로 확장에서 그리면 그림 2.와 같다.

먼저 Authorization Server로부터 Authorization Code를 발급 받아야 한다. 이는 Client에게

Access Token을 발급 받을 수 있는 자격을 주는 것으로 이해하면된다.

Authorization Code를 발급 받기 위해서는 Authorization Server가 결국 Resource Owner (User)를

인증할 수 밖에 없다. Authorization Code를 발급 받은 Client은 이제 Authorization Server로부터

Access Token을 발급 받을 수 있다. 이 때 이 Code를 통해서 Client를 인증하는 것이다.

결국 Authorization Server입장에서는 Resource Owner(User)와 Client 인증을 두가지를 수행하고 있다.

이는 Client Type이 Credential일 경우에 이 방식을 채용한다.

4.2. Implicit

Implicit 방식은 Client 인증이 존재하지 않는다. 따라서 Authorization Code Grant Type에서 Code를 발급받는 과정이 없다.

대신 Client의 인증은 Client 등록 과정에서 제공한 Redirection URL을 비교해서 등록했을 때 값과 비교하여 동일하면

Client 인증은 완료된다.

Client가 Access Token을 발급 받기 위해서는 Resource Owner의 인증과정은 필요하다.

따라서 이 방식은 Resource Owner (User) 인증만 존재한다.

4.3. Resource Owner Password Credentials

Resource Owner Password Credentials 방식은 Client가 Resource Owner에게서 받은 Credential 정보를

Authorization Server에 전달함으로써 Access Token을 발급 받는다.

Resource Owner가 Client에게 자신의 Credential을 전달하는 과정은 표준에서 다루지 않고 구현의 몫이다.

4.4. Client Credentials

Authorization Request 정보로 Client 자기 자신의 Credential을 사용하고 있다. Authorization Scope가 Client 자신에 해당하는 Resource에 한정되어 있을 경우만 사용한다. 또한 Client와 Resource Owner가 같은 경우에 주로 사용한다.

5. Access Token & Refresh Token

Access Token은 기본적으로 Scope과 Duration 속성을 가지고 있고, 정확한 포멧과 구조는 Security 요구 사항에 따라 구현단의 선택 몫이다. Duration은 10분 정도로 설정해서 사용하기를 권고하고 있다.

Refresh Token은 필수는 아니고 선택항목이다. Access Token을 재 발급 받기 위해서 사용되는 것으로 이 또한 Scope와 Duration 속성을 가지고 있다. Security 요구사항과 구현에 따라 구현단의 몫이다.

여기까지 추상적인 관점에서 전체 구성요소와 흐름을 알아 보았다. 이어지는 페이지에서는 좀 더 구체적으로 알아보도록 한다. 아래 그림은 전체 흐름에 대한 그림이다.

1. 목적

인터넷 상에도 많이 있는 예제 소스이지만, 차 후 빨리 찾기 위해서 여기에 기록해 둔다.

AES-256 CBC Mode 기반으로 암복호화 예제이다.

2. 간단설명

Openssl은 많은 Crypto 관련 함수를 가지고 있다. 직접 사용해서 코드를 작성해도 되지만 이들 함수를 한번 더 Wrapping한 EVP 함수 사용을 권장하고 있다. 아래 코드에서 암호화와 복호화를 따로 나누어서 처리했지만 둘의 구조를 보면 동일하다. EVP 함수 중에 둘 동작을 하나로 합쳐서 있는 코드를 사용하면 더 간단히 할 수 있다.

3. 소스 코드

#include <iostream> #include <fstream> #include <openssl/conf.h> #include <openssl/evp.h> #include <openssl/err.h> #include <cstring> #include <cstdio> void handleErrors(void) { ERR_print_errors_fp(stderr); abort(); } bool encrypt(const char *plain_path, const char *enc_path, unsigned char *key, unsigned char *iv) { int rsz = 0, wsz = 0, tsz = 0; std::FILE *fin, *fout; EVP_CIPHER_CTX *ctx; unsigned char rbuf[1024]; unsigned char wbuf[1024 + EVP_MAX_BLOCK_LENGTH]; std::memset(rbuf, 0x00, 1024); std::memset(wbuf, 0x00, 1024 + EVP_MAX_BLOCK_LENGTH); fin = std::fopen(plain_path, "rb"); if(fin == nullptr) { std::cout << "read file open fail" << std::endl; return false; } fout = std::fopen(enc_path, "wb"); if(fout == nullptr) { std::cout << "wirte file open fail" << std::endl; return false; } ctx = EVP_CIPHER_CTX_new(); if(1 != EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv)) { std::fclose(fin); std::fclose(fout); handleErrors(); } while((rsz = std::fread(rbuf, 1, 1024, fin)) > 0) { if( 1 != EVP_EncryptUpdate(ctx, wbuf, &wsz, rbuf, rsz)) { std::fclose(fin); std::fclose(fout); handleErrors(); break; } std::fwrite(wbuf, 1, wsz, fout); } if(1 != EVP_EncryptFinal_ex(ctx, wbuf + wsz, &tsz)) { std::fclose(fin); std::fclose(fout); handleErrors(); } std::fwrite(wbuf + wsz, 1, tsz, fout); std::fclose(fin); std::fclose(fout); EVP_CIPHER_CTX_free(ctx); return true; } bool decrypt(const char *cipher_path, const char *dec_path, unsigned char *key, unsigned char *iv) { int rsz = 0, wsz = 0, tsz = 0; std::FILE *fin, *fout; EVP_CIPHER_CTX *ctx; unsigned char rbuf[1024]; unsigned char wbuf[1024 + EVP_MAX_BLOCK_LENGTH]; std::memset(rbuf, 0x00, 1024); std::memset(wbuf, 0x00, 1024 + EVP_MAX_BLOCK_LENGTH); fin = std::fopen(cipher_path, "rb"); if(fin == nullptr) { std::cout << "read file open fail" << std::endl; return false; } fout = std::fopen(dec_path, "wb"); if(fout == nullptr) { std::cout << "wirte file open fail" << std::endl; return false; } ctx = EVP_CIPHER_CTX_new(); if(1 != EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv)) { std::fclose(fin); std::fclose(fout); handleErrors(); } while((rsz = std::fread(rbuf, 1, 1024, fin)) > 0) { if( 1 != EVP_DecryptUpdate(ctx, wbuf, &wsz, rbuf, rsz)) { std::fclose(fin); std::fclose(fout); handleErrors(); break; } std::fwrite(wbuf, 1, wsz, fout); } if(1 != EVP_DecryptFinal_ex(ctx, wbuf + wsz, &tsz)) { std::fclose(fin); std::fclose(fout); handleErrors(); } std::fwrite(wbuf + wsz, 1, tsz, fout); std::fclose(fin); std::fclose(fout); EVP_CIPHER_CTX_free(ctx); return true; } int main() { unsigned char *key = (unsigned char *)"31ACBFE93F0380049CFE9B236641E42E2832E05DDA5820A07D52CCB881C3308D"; unsigned char *iv = (unsigned char *)"00F037907D1DA656647B474DADE9C52C"; //encrypt("plain_text.ipk", "encrypted_2.ipk", key, iv); encrypt("test.txt", "encrypted.ipk", key, iv); decrypt("encrypted.ipk", "test1.txt", key, iv); return 0; }

4. CMakeLists.txt 파일

project (prj) set (BIN demo) cmake_minimum_required(VERSION 3.10) # Search OpenSSL find_package(PkgConfig REQUIRED) pkg_search_module(OPENSSL REQUIRED openssl) if( OPENSSL_FOUND ) include_directories(${OPENSSL_INCLUDE_DIRS}) message(STATUS "Using OpenSSL ${OPENSSL_VERSION}") else() # Error; with REQUIRED, pkg_search_module() will throw an error by it's own endif() add_definitions(-std=c++1z) add_executable(${BIN} test.cpp) target_link_libraries(${BIN} ${OPENSSL_LIBRARIES})

1. 목적

TLS 통신을 하는 Server와 Client를 실제로 만들어서 테스트 해 보았다.

일단 Self Signed Root 인증서를 만들고, Server와 Client 각각의 인증서를 Root CA로 서명해서 사용했다.

2. 인증서를 생성

[ Self Signed Root CA 생성 ]

> openssl genrsa -out CAPriv.pem 2048 > openssl req -new -key CAPriv.pem -out CAReq.pem > openssl x509 -req -days 3650 -in CAReq.pem -signkey CAPriv.pem -out CACert.pem

[ Server 인증서 생성 ]

> openssl req -new -keyout ServerPriv.pem -subj '/C=KR/ST=KR/O=test/CN=server' -out ServerReq.pem > openssl x509 -req -days 365 -CA CACert.pem -CAkey CAPriv.pem -CAcreateserial -in ServerReq.pem -out ServerCert.pem > openssl verify -CAfile CACert.pem ServerCert.pem

1. 목적

Server와 Client간의 HTTPS(TLS)통신을 위해서는 인증서가 필요하다. Client단에서 Server를 인증하기 위해서는 Server단에서 Client단으로 인증서를 내려주고, 그 인증서를 공인 CA 인증서로 확인을 해야 한다. 이 과정에서 공인 CA의 경우에는 비용 지불이 필요하다. 여기서는 비용이 들지 않는 CA를 직접 만들어서 사용하는 것을 정리한다. 이 CA를 Self-Signed CA라고 보통 말한다.

공인 인증서는 각 인증서를 검증하는 단계가 존재하고 이 구조는 보통 Tree 구조로 형성된다. 이 단계에서 최상위 단계를 Root CA라고 한다. 여기서 만드는 Self-Signed CA는 어차피 내가 만들어서 사용함으로 이 인증서 자체가 최상위 단계에 있는 것과 동일함으로 최종적으로 Self-Signed Root CA가 되는 것이다.

2. 인증서 발행 절차

인증서 발행 절차를 단계별로 정리한다.

2.1. 개인키 생성

Server와 Client는 이 단계를 동일하게 수행한다.

[ RSA기반 개인키 생성 ]

> openssl genrsa -out private.pem

[ RSA기반 개인키 생성 (nodejs) ]

spawn = require('child_process').spawn let keyArgs = ['genrsa', '-out', 'private.pem', '2048']; spawn('openssl', keyArgs, {stdio: 'pipe'}).on('exit', (code) =>; { if (code !== 0) { process.umask(oldmask); return reject(new Error("error generating key: return code " + code)); } });

상세 옵션은 링크 참조 : https://www.openssl.org/docs/man1.0.2/apps/genrsa.html

2.2. CSR 생성

인증기관으로부터 공식적인 인증서를 받기 위한 신청서를 생성하는 단계로 신청서 양식이 CSR(Certificate Signing Request)라고 이해하기로 함. 신청자를 구분하고자 몇가지 정보를 입력해야 함.

[ CSR 생성 (command line 명령어) ]

> openssl req -config ./openssl.cnf -subj '/C=KR/ST=Seoul/O=My Home/OU=My Home/CN=My Home/' -key private.pem -new -sha256 -out certificate.csr

• -config 옵션을 주지 않으면 default configuration file을 사용한다.
• -subj 옵션을 주지 않으면 CSR 생성시 필요한 각 항목에 대해서 사용자 입력을 요구한다.
• -key 옵션은 여기서는 2.1.절에서 생성한 개인키를 입력한다.

[ local openssl.cnf ]

[ req ] # Options for the `req` tool (`man req`). default_bits = 2048 distinguished_name = req_distinguished_name string_mask = utf8only # SHA-1 is deprecated, so use SHA-2 instead. default_md = sha256 # Extension to add when the -x509 option is used. x509_extensions = v3_ca [ req_distinguished_name ] countryName = Country Name (2 letter code) stateOrProvinceName = State or Province Name localityName = Locality Name 0.organizationName = Organization Name organizationalUnitName = Organizational Unit Name commonName = Common Name emailAddress = Email Address

openssl req 단계에서는 openssl.cnf 파일에서 [req] section을 참조한다.

[ CSR 생성 (nodejs 코드) ]

let csrArgs = ['req', '-config', './openssl.cnf', '-subj', '/C=KR/ST=Seoul/O=My Home/OU=My Home/CN=My Home/' , '-key', './private.pem', '-new', '-sha256', '-out', 'certificate.csr']; spawn('openssl', csrArgs, {stdio: 'pipe'}).on('exit', (code) => { if (code !== 0) { return reject(new Error("error generating csr: return code " + code)); } });

상세 옵션은 링크 참조 : https://www.openssl.org/docs/man1.0.2/apps/req.html

2.3. CA(Certification Authority) 통하지 않고 인증서 만들기

일반적인 인증서 발급 절차는 2.2.까지 CSR를  생성하고 CA에 CSR를 보내서 CA가 인증한 인증서를 취득한다.

위는 우리가 개발자라서 관심이 있지만 일반인은 그냥 인증서 발급 기관에서 간단한 개인정보만 입력하고 발급 받는 것이 일반적이지 않을까 생각이 든다.

아래에서 설명할 내용은 이미 네 서버에 CA가 존재하고 이 CA로 내 인증서를 Signing하는 방법에 대해서 알아본다. 왜 이런 것이 필요할까? 공식 인증기관은 돈이 들고, 또 이런 것까지 필요없는 단순 TLS(SSL) 구현부에서

자체 Client/Server 통신을 위해서 필요하다해서 관심을 갖는다.

[ CA로 Signing 된 인증서 생성 (command line 명령어) ]

> openssl ca -config ./openssl.cnf -extensions v3_ca -days 7300 -notext -md sha256 -in certificate.csr -out certification.pem -batch

[ CA로 Signing 된 인증서  생성 (nodejs 코드) ]

let certArgs = ['ca', '-config', ./openssl.cnf '-extensions', 'v3_ca', '-days', '7300', '-notext', '-md', 'sha256', '-in', CSR_PATH, '-out', certification.pem, '-batch']; spawn('openssl', certArgs, {stdio: 'pipe'}).on('exit', (code) => { if (code !== 0) { return reject(new Error("error generating cert: return code " + code)); } })

[ local openssl.cnf ]

[ CA_default ] # Directory and file locations. dir = /home/hskim/project/nodejs/ certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/newcerts database = $dir/index.txt serial = $dir/serial RANDFILE = $dir/.rand # The root key and root certificate. private_key = $dir/rootCA/rootca.key.pem certificate = $dir/rootCA/rootca.cert.pem # For certificate revocation lists. crlnumber = $dir/crlnumber crl = $dir/crl.pem crl_extensions = crl_ext default_crl_days = 30 # SHA-1 is deprecated, so use SHA-2 instead. default_md = sha256 name_opt = ca_default cert_opt = ca_default default_days = 375 preserve = no policy = policy_strict

openssl ca 단계에서는 openssl.cnf 파일에서 [ca] section을 참조한다.

네가 가지고 있는 CA로 Signing한 인증서를 만드는 가장 핵심은 openssl.cnf를 들어다봐야 이해할 수 있다.

현재까지 생성한 개인키와 CSR를 어디선가 받거나 자체 생성한 CA로 Signging하도록 지시하는 부분은 openssl.cnf 파일에 설정되어 있다. 

내 인증서를 CA로 인증할 Root CA의 private_key, certificate의 위치를 openssl.cnf에 기술되어 있다.

이를 기반으로 CA를 적용하여 내 인증서를 Signing한다.

만약 configuration 파일에 해당 항목이 지정되어 있지 않다면 아래 항목에 기술한다.

• -cert : CA certification 위치 지정
• -keyfile : CA private key 위치 지정

사실 위 옵션은 command line에서 해 보지는 않았지만 맞을 것이다.

상세 옵션은 링크 참조 : https://www.openssl.org/docs/man1.0.2/apps/ca.html

3. Self Signed Certification Authority (SSCA)

2.단계에서 CA 인증서를 사용하여 내 인증서를 Signing했다. 그렇다면 자체 CA는 어떻게 만들 것인가?

외부에서 받을 수도 있지만 여기서는 공식 인증기관이 아닌 자체적으로 Root CA를 만드는 과정에 대해서 설명한다.

그 절차는 2.단계에서 보았던 것과 동일하다. 일단 개인키를 만들고, 그 다음 CSR까지 동일하게 만든다.

마지막 CA 단계에서 x509 옵션을 사용한다.

[ SSCA 인증서 만들기 ]

> openssl req -new -x509 -days 7300 -key private.pem -out ssca.crt or > openssl x509 -req -in certificate.csr -extfile openssl.cnf -extensions v3_ca -signkey private.pem -out cacert.pem

[ -extensions v3_ca openssl.cnf ]

[ v3_ca ] # Extensions for a typical CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign

4. 인증서 확인 방법

인증서는 기본적으로 base64 encoding 되어 있어서 내용을 확인하기 위해서는 openssl x509 명령어를 사용한다.

[ x509 명령어 ]

openssl x509 -in cert.pem -noout -text // subject 출력 openssl x509 -in cert.pem -noout -subject

openssl x509 명령어를 통해서 인증서 내용확인, 변환, Self Signed CA 생성등의 일을 할 수 있다.