보안

대칭키와 비대칭키, OAuth 에 대하여

HootJem

Sep 19, 2024

Contents

CIA 대칭키 암호화 방식 RSA암호화 (비대칭키)HTTPS

CIA

기밀성 - Confientiality 무결성 - Integrity 가용성 - Availability

정보 보안의 3대 요소인 CIA는 기밀성, 무결성, 가용성으로 구성된다. 이를 기반으로 통신과 암호화 기술은 발전해 왔다.

A 는 1234 를 B 로 보내려고 한다. 이때 C 가 간섭을 하려할 때 1234 라는 평문(p) 로 보내게 되면 C는 쉽게 간섭이 가능하고, 탈취하여 다른 텍스트를 보낼 수 있게 된다.

이는 무결성이 깨지는 이유가 된다.

따라서 PlainText 를 인크립트 하여야한다.(암호화)

1234 를 qwer 로 암호화 하여 B 로 보냈을 때 암호화된 qwer 의 정체를 알기 위해서는 어떻게 암호화를 하였는지 암호화 방식도 함께 보내야 한다.

또다시 C가 탈취를 하여 B 로 위변조된 5678 을 보냈을 때 B는 중간에 온 5678을 해석하려 한다. 이는 약속된 A 에서 온 암호인지, C 에서 온 암호인지 구분할 수 없기 때문이다. → 신뢰성 또한 5678은 B 가 알고있는 암호가 아니기 때문에 활용할 수 없다. → 가용성에 문제가 생김

우리는 CIA 와 신뢰성의 문제를 마주하게 된다.

대칭키 암호화 방식

대칭키 암호화는 비밀키를 통신 당사자가 공유한다.

아래의 그림에서 키는 5 에 해당한다. (공개라고 적은 이유는 C가 훔쳐갔기 때문.)

A가 3, 키 5를 갖고있고, B가 4, 키 5을 공유한다. 이때 C는 A,B 가 공유한 키 값 5 을 알고있다.

A와 B는 각각 자신의 비밀키로 연한을 수행한 값인 A의 15, B 의 20을 서로에게 전달한다.

서로의 값을 받아 다시 자신의 비밀키로 곱하면 60이 나온다. 이처럼 대칭키를 만들 수 있는 알고리즘을 주고 받는 것을 대칭키라고 한다. (알고리즘을 통해 암호화, 복호화가 이루어진다.)

이때 C가 통신으로 교환된 것은 알 수 있다고 할 때

최소공약수를 계산하여 각자의 비밀키를 예측할 수 있게 된다. 숫자가 커질수록 계산이 오래걸릴 수 있으나 해석이 가능하다는 문제가 있다.

RSA암호화 (비대칭키)

문을 열기 위해서 공개키로 잠궜으면 비공개키, 비공개키로 잠궜으면 공개키로만 열 수있다. 반대되는 키가 필요하다는 것. (공개키, 비공개키가 쌍으로 이루어지지만, 복호화를 위해서는 반대 키가 필요하다.)

1234를 A의 공개키로 암호화하면 A만 복호화할 수 있다. 반대로 A의 비공개키로 암호화하면 누구든지 A의 공개키를 통해 데이터를 열어볼 수 있다.

B만 열어볼 수 있도록 하고 싶다면, B의 공개키로 데이터를 암호화 해야한다.

→ C: 보안 해결!

이때 공개키 들은 모두 공개되기 때문에 C가 중간에 끼어들어 암호를 변경한 뒤 B 공개키로 암호화 하여 위변조된 값 전달이 가능하다.

(A에서 전달한 값이 B까지 가지 않기 때문에 무결성이 위반되었다.)

무결성 (Integrity)

데이터의 무결성을 보장하기 위해서는 다음과 같은 과정을 실행할 수 있다.

A의 비공개키(=개인키)로 다시 묶는다. 이후 B에게 프로토콜을 전달한다. 프로토콜을 생각해 보자.

프로토콜

A의 공개키로 풀기 (신원 증명)

B의 개인키로 풀기 (암호화)

데이터 읽기

이러한 형태를 띄게 된다.

이러하면 가용성도 자동으로 해결할 수 있다. B의 프로토콜 단계에서 실패하면 키를 버리고, 해석이 된 데이터는 쓸 수 있는 데이터기 때문이다.

보통 이렇게 a가 전송되는 형태는 TCP 통신으로 실행된다. TCP 통신에서는 Three-Way Handshake가 이루어지는데, 연결을 설정하기 위한 기본적인 절차는 이러하다.

단순히 A가 응답을 받는 것으로 끝나는 것이 아니라, 서버의 응답을 클라이언트가 다시 확인해야 비로소 연결이 확립되고, 그 이후에 본격적인 데이터 전송이 시작된다.

이렇게 양방향으로 확인하는 절차 덕분에 신뢰성 있는 데이터 전송이 가능해지는것.

비대칭키 예시

은행에서 이체를 하려 하면 그냥은 할 수 없다. 은행이 개인에게 공인인증서를 발급해주면, 공인인증서를 사용하여 이체를 할 수 있게 된다. 이 공인인증서는 개인키 에 해당하고 은행 DB 에서는 저장해 놓을 수 없다.

ssar 이 개인키를 들고 이체를 하러 왔다.

이후 db 에 저장되어 있는 1.공개키로 암호화를 풀 수 있다.

HTTPS

CA기관에서 공개키, 개인키 발급을 해준다. 내 블로그를 만들고 싶을때 키 발급을 위해 CA 기관에 요청을 한다. (당연히 유료임)

그럼 SSL 인증서를 준다.

ssar 이 id, 암호 로 블로그에 요청한다. 최초 1번은 CA기관으로 넘겨 인증을 시키고, CA 기관은 공개키를 보내준다. ssar 은 공개키로 정보를 잠궈 블로그에 데이터를 보낸다. 블로그 서버는 통신이 성공된것을 확인하면 갖고있는 개인키로 ssar 의 데이터를 열어볼 수 있다.

출처확인은 불가하기 때문에 세션 혹은 토큰으로 하게된다.

왜 세션말고 JWT 썻니? 서버가 늘어나면 세션이 공유가 안되어서 물론 Redis 로도 해결이 가능하긴 한데 프론트마다 세션과 JWT 를 쓰는 경우가 다른데 통일하는게 맞다고 생각해서 JWT 씀.

JWT(JSON Web Token)

JWT란? 전자서명을 통해 인증하는 방식 특징 : 클라이언트의 상태를 저장한다. 대칭키 → 서버만 풀어볼 수 있다. 공개키 → 누구나 풀어볼 수 있다.

JWT 안에는 개인 정보가 들어가면 X, 서버만 알 수 있는 PK 가 들어가면 됨.

클라이언트가 Love, 1234 로 로그인 요청을 한다. DB 의 pk 인 3을 리턴할때 이때 3은 서버의 개인키 에 해당하고 클라이언트가 개인키로 암호화하여 요청을 하면 서버는 앞으로 개인키로 풀어볼 수 있다.

JWT 에 Authorization 으로 리턴이된다. 클라이언트의 로컬스토리지에 JWT 를 저장한다. (쿠키에 저장할 수 있는 코드를 짜야함)

비밀키로 풀리면 신뢰할 수 있는 데이터, 안되면 인증이 안되었다는것. 상태정보는 클라이언트가 들고오게 되게 때문에 서버는 공개키만 들고있으면 된다.

대칭키, 공개키 기반 둘 다로도 만들 수 있음. (키 교환을 안하고 서버가 잠구고, 풀고 다 해서)

→ 만약 OAuth 사용시 잠구는 역할과 푸는 역할이 다르기 때문에 대칭키로 할 수 없음.

OAuth

OAuth란? 대리인에게 위임한다는 것.

이때 유저가 대리인에게 인증서를 보여주며 천만원을 빌려주면 이천만원을 값는다고 한다. 이때 대리인은 인증서를 믿을 수 없기 때문에 인증서를 확인해 보아야한다.

대칭키 인증서 : 은행가서 풀어보자.

비공개키 인증서 : 공개키로 풀어보자.

이런느낌. 즉 은행접근 권한을 대리인이 대신할 수 있게 권한을 위임하는 것.

이렇게 이름을 바꿔볼 수 있다.

대리인의 입장에서 유저 가 은행에서 받아온 인증서가 유효하기 때문에 은행과 유저를 신뢰할 수 있다.

블로그는 카카오에 엑세스 토큰에 해당하는 유저의 정보를 받는다 (이메일, pk, 사진 등) 블로그에서 그 리턴된 정보를 사용하여 JWT 를 생성한다.

블로그에서 해당 회원의 JWT 를 생성하고 나면 엑세스토큰이 없어도 된다. 이는 oauth 가 대칭키로 만들어진거라 그런것. 만약 RSA 기반으로 만들어 졌다면 공개키만 받으면 되기 때문에 블로그에서 JWT 를 생성할 필요가 없다.

만들어진 JWT 를 브라우저(유저) 에게 리턴해 주고 이 JWT를 HTTP쿠키나 로컬스토리지에 저장한다. 이후 요청이 필요할 때 마다 저장된 JWT 를 사용하여 인증을 하게된다.

See more posts

보안

CIA

대칭키 암호화 방식

RSA암호화 (비대칭키)

무결성 (Integrity)

비대칭키 예시

HTTPS

JWT(JSON Web Token)

OAuth

More articles

[v4] JWT 필터링

[v4] RestAPI 변경 및 JWT 발급

[v3] springboot 블로그 만들기-8

[v3] springboot 블로그 만들기-7