IT
"비밀번호보다 안전”… 카카오페이 암호화 논란에 전문가 반박
R

Lv.1 rymerace (115.♡.71.196)

2025년 4월 16일 AM 07:17 · 수정됨(04. 18. 22:55)

조회 2,380 공감 0


카카오페이, 일방향 암호화(SHA-256)
금감원 "복호화 가능" 주장에 반론 확산
정보 이전 성격도 법정 공방 예고


[이데일리 김아름 기자] 카카오페이가 알리페이에 이전한 정보의 암호화 수준을 두고 논란이 이어지는 가운데, 해당 암호화 방식이 일반 비밀번호 보호보다 더 안전하다는 전문가 의견이 제기됐다.


15일 업계에 따르면, 논란의 중심은 카카오페이가 사용한 암호화 방식 ‘SHA-256’이다. 이 방식은 미국 국립표준기술연구소(NIST)에서 개발해 국제 표준으로 채택된 암호화 해시 함수로, 현재도 공공기관과 민간 기업에서 널리 사용되고 있다.

김승주 고려대학교 정보보호대학원 교수는 “SHA-256은 일방향 암호화 방식으로, 복호화 자체가 불가능한 구조”라며 “이를 ‘뚫을 수 있다’는 주장은 잘못된 이야기다. 미국 표준으로 지금도 전 세계적으로 쓰이는 안전한 방식”이라고 설명했다. 그는 “우리가 일상적으로 사용하는 비밀번호도 모두 일방향 암호화 방식으로 보호되고 있다”며 “SHA-256은 이러한 비밀번호 보호 방식과 동등하거나 더 높은 수준의 보안성을 갖춘 기술”이라고 강조했다.

이는 금융감독원이 제기한 “일반인도 복호화할 수 있다”는 주장과는 상반된 입장이다. 앞서 금융감독원은 지난해 8월 보도참고자료를 통해 카카오페이가 알리페이에 이전한 정보의 암호화 수준이 일반인도 복호화할 수 있을 만큼 취약하다고 지적한 바 있다. 특히 전화번호, 이메일 등 민감한 정보에 솔트(Salt, 무작위 값)를 적용하지 않았다는 점을 문제 삼았다.

김 교수는 “금감원 논리대로라면, 현재 사용 중인 대부분의 비밀번호 보호 체계 역시 불완전하다는 결론에 도달하게 된다”고 지적했다.

같은 맥락에서 개인정보보호위원회 역시 카카오페이가 제공한 정보가 암호화됐다고 명시하며 별다른 문제를 제기하지 않았다.


아울러 이데일리가 입수한 개인정보보호위원회 전체회의 속기록에서도 금감원 주장에 대한 반박이 제시됐다. 카카오페이는 고객번호, 휴대전화번호, 이메일 주소 등 개인정보를 일방향 해시 방식으로 처리해 복호화가 불가능한 형태로 전송했으며, 식별 가능성이 높은 정보에는 솔트 기법을 추가 적용해 재식별을 원천 차단했다고 밝혔다. 이 때문에 알리페이 측에서도 원본 데이터를 확인할 수 없는 구조라고 했다.

댓글 (21)

  • 대화상자

    대화상자 Lv.1

    25.04.16 · 211.♡.102.233

    일반인도 할수는 있겠죠. 시간과 데이터의 양이 문제지. 금감원에서 저렇게 이야기 한 근거가 뭔지 궁금하기는 하네요.
  • 구구탄별

    구구탄별 Lv.1

    25.04.16 · 112.♡.250.170

    [https://damoang.net/data/editor/2504/comment_1891367594_cgIOukyF_97c4da120a1d1f92e40690ea08211aaafe38869a.jpeg]
  • aicasse

    aicasse Lv.1 → 구구탄별

    25.04.16 · 203.♡.190.49

    주민등록번호가 숫자 13자리인데, 마지막 자리는 체크섬이고, 두번째 부분에 첫 자리는 성별 구분이라 많은 경우 이미 예측 가능하죠. (그게 아니어도 모든 숫자가 다 쓰이지 않고.) 기타 등등 따져보면 아마 대강 실제 불확실한 부분이 숫자 10자리 정도로 보면 될 겁니다. 아니, 그냥 속편하게 체크섬 뺀 12자리라고 해도, 숫자 10자리 탐색하는 시간의 100배 걸리는 거죠. 평균 이천분의 일초.

    카카오계정과 애플id 사이의 매칭을 확인하기 위한 거였으니, 설령 솔트를 썼다 해도 매칭 확인을 위해서는 솔트도 같이 제공해줬을 거고, 제공받은 솔트로 주민등록번호 가능한 거 다 만들고 체크섬 붙여서 계산하면, 알고리즘의 차이도 있고 아키텍춰의 차이도 감안하고 해서 오차를 넉넉하게 고려한다고 해도, (매우 많이) 넉넉잡아 1초면 하나씩은 나올 겁니다. 대단히 심오한 무엇도 아니고, 그냥 챗지피티한테 이런 거 만들어달라고 하면 아주 잘 해줄 듯...
  • 긴급휴무 Lv.1

    25.04.16 · 211.♡.71.91

    전화번호에 SHA256적용해도... 전화번호의 패턴이란게 있으니 무작위대입에 뚫릴텐데요. 애초에 전화번호 따위는 레인보우테이블이 이미 있을거 같네요.
  • BLUEnLIVE

    BLUEnLIVE Lv.1

    25.04.16 · 211.♡.234.109

    저건 그냥 금감원이 막 우기는 거죠.
    이론적으로야 Salt를 넣는다고 해도 100% 안전한 게 아니잖아요.....
    이론적으로야..........
  • 경사 Lv.1 → BLUEnLIVE

    25.04.16 · 222.♡.114.172

    전화번호는 솔트 적용 안했으면 암호화 안한거나 다름없죠. 적용여부가 쟁점인데 양쪽 말이 갈리네요.
  • aicasse

    aicasse Lv.1 → 경사

    25.04.16 · 203.♡.190.49

    솔트 적용해도 마찬가지죠. 매칭을 위해서는 솔트 또한 저장되어 있어야 하니...
    지금 문제가 카카오페이 계정과 애플id 계정과의 매칭을 위해서라고 하니, 아마도 사용한 솔트를 제공하지 않고서는 방법이 없을 겁니다.

    낮은 엔트로피의 데이터는 해쉬함수로는 답이 없습니다.
  • 경사 Lv.1 → aicasse

    25.04.18 · 211.♡.74.96

    솔트를 제공한다는게 이해가 안가네요. 알리가 평문 전화번호를 입력받아서 비교할게 아니고서야 솔트가 왜 필요하죠...?
  • aicasse

    aicasse Lv.1 → 경사

    25.04.18 · 203.♡.190.49

    물론, 정황상 솔트 자체를 안 쓴 것 같기는 하므로 별 의미없는 이야기이기는 합니다.
    하지만, 솔트 적용을 했는지가 쟁점이라면, 만약에 솔트를 적용했다고 했을 때,
    그렇게 적용한 솔트를 전달했을까를 한번 생각해볼 수는 있겠죠.
    (가정에 가정을 거듭하는 거라... 이게 얼마나 의미있는 이야기인지는 모르겠습니다.)

    하지만 솔트가 s이고 메시지가 m이라고 하면, 그렇게 얻어지는 해쉬값 H(s, m)은,
    해쉬 함수가 정상적이고 합리적으로 만들어졌다고 할 때 (SHA-256이니 대충 그렇다고 쳐도 될 것 같습니다)
    그리고 솔트가 충분히 길어서 예측 불가능하다고 하면,
    솔트를 모르는 사람의 입장에서는 의사난수함수(PRF)라고 볼 수 있겠죠.
    그러니 그냥 순수한 랜덤함수 R(m)과 구별되지 않는다고 볼 수 있습니다.

    그렇다면, 솔트를 제공하지 않는다고 하면 카카오페이에서 알리페이에게 그냥 정말로
    100% 의미없는 난수만을 전달한 겁니다. 왜 그래야 할까요? 차라리 개인정보를
    안 보내는 것이 낫지 않을까요.

    보통 솔트를 적용했다고 할 때, 사전 계산 공격을 차단하는 용도로 적용했다고 생각하지,
    솔트 제공을 거부해서 해쉬를 아무런 의미없게 만들겠다...라고 생각하지는 않을 것 같습니다.

    예를 들어 애플id 쪽에 전화번호가 있을 수도 있겠죠. 그걸 카카오계정 가입자와 비교할
    목적일 가능성도 있을 것 같습니다. 하여튼, 정확한 시나리오는 언론이나 금융감독원을 통해
    공개된 내용만으로는 파악하기 조금 어렵습니다.
  • 경사 Lv.1 → aicasse

    25.04.18 · 211.♡.74.96

    좀 이상해서 찾아보니 제가 생각한 개념은 salt가 아니라 pepper라고 부르나보네요... ㅎㅎ

댓글을 작성하려면 이 필요합니다.