개인정보 필드 암호화 대응기

들어가며

최근에 금융권 특정 기관과 전용선으로 통신하던 환경에서, 개인정보 필드에 대한 암호화 요구사항을 받았다. 전용선을 사용할 때 네트워크 레벨에서 보안이 지켜진다면 특별히 필드 암호화를 할 필요는 없다는 것으로 정리하고 초기 프로세스를 구축했으나, 아마 기관 측 내부 감사 등의 사유로 정보보안 강화 차원에서 진행하려는 것으로 보였다.

기존에 암복호화는 공통 모듈에서 제공하는 인터페이스를 통해 이루어져와서, 암복호화 모듈에 대한 협의는 해당 부서에서 진행하고, 단위 업무에서는 application 레벨에서의 도메인 로직에만 집중하면 되는 것으로 생각하였다. 하지만 기존 공통 모듈에서 제공하는 기능이 기관 측 암호화 요구사항을 충족하지 못하는 문제를 발견하였다.

 

기관 측 암호화 요구사항

기관 측에서 요구하는 암호화 프로세스는 다음과 같았다.

원본 source data가 있고 최종적으로 encryption data를 파일로 주고 받는 것이다. 이 때 암호화는 다음의 단계를 따르는 것으로 가이드를 받았다.

고객의 개인정보에 해당하는 source data가 있다고 할 때 다음의 단계를 따른다.

• nibble 단위 변환 (8byte)
• AES256/CBC/PKCS5Padding (16byte)
• Base64 encoding (24byte)

최종적으로 24byte 문자열을 통신하는 것이다.

source data는 문자열로 숫자만 사용하며, 8자리 또는 16자리고, 기본적으로 16byte 숫자 이내의 데이터라면 fixed 8byte, 16nibble 크기의 데이터로 변환 후 암호화하는 요구사항이었다.

 

사내 공통 암복호화 모듈 한계

기본적으로 암호화 시에 byte array를 기본으로 동작하는데, 기존에 회사에서 제공하는 공통 모듈에서는 (아마 편의성을 위해) 원본 문자열을 요청 파라미터로 받아 처리하는 구조였다.

따라서 nibble 단위로 변환 시에 이를 readable한 문자열로 변환하여 전달할 때의 필요조건은 원본 byte 데이터를 훼손하지 말아야 하는 것이지만, 모듈 내부적으로 문자열을 해석하는 방식이 단순 toString() override 데이터로 해석하는 것이어서, byte array를 넘기면 해당 값의 hash 값을 암호화하는 왜곡이 발생할 수밖에 없었다.

처음에는 별 생각 없이 모듈을 사용해서 왜 암호화한 결과가 32byte가 나오는지 몰랐는데, 디버깅 과정에서 공통 모듈을 분석하며 위와 같은 문제점을 발견할 수 있었다.

문제 발견을 위해 로컬에서 테스트하는 과정을 거쳤는데, jdk 내장 라이브러리를 이용해 aes 암호화를 수행했고, 기관 간 공유하는 대칭키(secret key)와 iv를 받아서 스펙 초기화 후 암호화하였더니, 기관 측에 요청하여 받았던 예시 암호화 결과값과 일치하는 결과를 얻을 수 있었다.

 

공통 모듈 개선 방향 제시

대칭키는 HSM(Hardware Security Module)에서 보관하고 있었다. HSM 연동을 단위 업무 레벨에서 직접 구현할 것이 아니라면 기존에 HSM과의 연동 로직을 포함하는 공통 모듈을 사용하는 것이 합리적이었기 때문에, 해당 부서 담당자에게 문제 상황을 공유하고 논의를 시작하였다.

다음의 2가지 대안을 제시하였다.

• byte array를 요청 파라미터로 받을 수 있는 구조로의 변경
• 문자열로 요청 파라미터를 받는다면 byte array 데이터를 훼손하지 않는 encoding/decoding 로직 추가

이 때, 문자열 변환을 위해서는 Base64 encoding 또는 hex encoding(기존 모듈에서 채택하던 방식이었기에 함께 제시하였다)을 제시하였고, 이 중에서는 RFC 표준으로 더 많이 사용하는 Base64 encoding을 더 우선적으로 제안했다.

 

마치며

당장 주말 직전 퇴근 전에 논의를 시작하여서 해당 부서 담당자 사정으로 다음주 월요일에 다시 논의하기로 하였다. 내가 공통 모듈의 사용법을 제대로 파악하지 못했을 가능성도 있어서, 우선은 해당 담당자와 추가 논의하여 결정하기로 하였다. 아마도 HSM 연동 암복호화 인터페이스가 내가 사용한 모듈의 메서드 외에 더 존재하지 않는다면, 아마 제안한 내용 중에 하나로 로직이 수정되지 않을까 싶다. 그럼에도 불구하고 요구사항을 충족할 수 있는 더 간단한 방법이 있다면 해당 방법을 채택하여 진행하지 않을까 싶다.