이메일에서 쓰는 메시지 암호화

보안 관점에서 볼 때 서버는 기본적으로 네트워크 상에서 오는 메시지들은 믿어서는 안됩니다. 그래서, 클라이언트로부터 오는 메시지를 믿기 위해 여러 관문들과 장치를 만듭니다. 네트워크 레벨에서는 HTTPS 로 man in the middle 공격을 막으려고 노력하고, HSTS 도 쓰고, IP 기반으로 ban 도 하고, 등등... 여러 레이어에서 여러 방법으로 처리를 합니다. 그런데 이메일에서는 쓸 수 있는 방법이 제한적입니다. 그래서 기본적으로 이메일의 링크를 통해서 유저가 데이터베이스에 미치는 영향은 제한적이어야 합니다. 그럼에도 필요한 경우들이 있는데 (e.g. email unsubscribe) 그럴 때 메시지 암호화를 씁니다. 암호화 방법도 다양합니다. 복호화가 가능한 양방향 암호화와, 복호화가 안되는 단방향 암호화, 대칭키 암호화와 비대칭키 암호화 등 다양하게 분류하죠. 그 중에서 저는 단방향 암호화인 SHA-256 과 대칭키 암호화인 AES 를 주로 씁니다. 따로 쓰지 않고, 같이 씁니다. 예를 들면 다음과 같습니다. 서버에서 검증이 필요한 주요 데이터는 SHA-256 으로 hexdigest 를 만든 뒤, 이를 덜 민감한 다른 데이터와 함께 AES 로 말아서 이메일에 심습니다. 그리고 해당 메시지가 request 로 들어오면, 서버는 이전에 특정 유저에게 보냈던 메시지임을 인지하고, 약속한 특정 행동을 합니다. 이중으로 암호화를 한 이유는 다음과 같습니다. AES 암호화에 쓰이는 키는 절대 서버 밖으로 나가서는 안됩니다. 그럼 compromise 될 가능성이 훅 올라갑니다. 그럼에도, 몹시 희소하지만 brute force 로 뚫을 수 있는 방법도 여전히 존재는 하죠. 이메일로 한 번 나간 메시지는 어떻게든 구워삶아질 수 있다고 가정해야 합니다. 그렇게 해서 뚫렸을 때 민감한 정보가 바로 보이면 위험하죠. 그래서 그 안에 민감한 데이터를 바로 두는 것이 아니고, SHA-256 으로 만든 digest 를 두는 것입니다. 서버는 AES 복호화 키를 가지고 있기 때문에 암호화된 메시지의 기본 형태를 알 수 있습니다. 그리고 덜 민감한 데이터들로부터 힌트를 얻어서, 어떤 값들을 input 으로 SHA-256 해싱을 했을 때 digest 가 나올지 유추할 수 있습니다. 그렇게 digest 를 만들었을 때 만약 메시지에 있는 digest 와 동일한 값이 나오면 authentic 하다고 인정해줍니다. 그렇지 않을 땐 bad request 처리를 해주고요. 폰으로 길게 쓰려니 힘드네요 😅 암튼 저는 메시지 암호화를 위와 같이 쓰고 있는데, 다른 분들은 어떤 용도로 어떤 방식으로 쓰시는지도 궁금하네요. 🙂 제가 삽질을 하고 있는 것 같다면 알려주셔도 좋겠습니다 ㅎㅎ