금융기관 인증·조회 백엔드 신규 구축

서명은 브라우저가 만들어 주지 않습니다

인증서 로그인은 페이지 조작만으로 통과되지 않습니다. 금융기관이 받는 값은 인증서로 만든 전자서명이고, 그 서명은 PC에 설치된 보안 모듈이 사람의 비밀번호 입력을 받아 만들어냅니다. 로그인을 자동화하려면 이 서명을 직접 만들어야 했습니다.

요청·응답과 보안 모듈 동작 분석

기관별로 로그인 요청과 응답을 캡처해 어떤 값이 어떤 순서로 오가는지 따라갔습니다. 서명이 만들어지는 지점은 브라우저 밖의 설치형 보안 모듈이라 코드를 읽을 수 없었고, 모듈이 내놓은 결과물을 리버스 엔지니어링해 무엇을 서명 대상으로 삼고 어떤 값을 함께 넣는지 역산했습니다. 서명 대상, 함께 담기는 속성과 인코딩은 기관마다 달랐습니다.

개인키 복호화와 서명 생성을 Java로 구현

공동인증서 개인키 파일은 표준 PKCS#8 외에 국내 표준 블록 암호를 쓰는 형식이 섞여 있습니다. 형식과 키 유도 방식을 판별해 복호화하는 처리를 직접 구현했습니다.

기관별 계약과 작업 실행 경계

복호화한 키로 서명을 만드는 코드는 기관별 Signer로 나누고 Factory가 요청에 맞는 구현을 선택하게 했습니다. 로그인과 조회 흐름은 기관별 Adapter에 담아 요청·응답 차이가 다른 기관의 흐름으로 번지지 않게 했습니다.

여러 작업은 직렬·병렬 실행 조건에 따라 queue에 넣고, watchdog이 실행 상태를 확인하며 완료 결과는 cache에서 조회하도록 구성했습니다.

실제 사용자 정보 없이 회귀 검증

주요 인증·조회 흐름은 합성 데이터와 미리 저장한 응답으로 반복 실행했습니다. 서명은 입력과 시각을 고정한 뒤 기대한 바이트와 같은지 골든 벡터로 비교해 암호 처리나 인코딩 변경을 확인했습니다.

인증서 로그인과 계좌 조회는 실제 금융기관 환경에서 동작을 확인했습니다. 기존 자동화 경로를 유지한 채, 브라우저 없이 직접 통신하는 경로로 옮기는 작업을 진행하고 있습니다.

설치형 전환의 두 산출물 경계

고객 인증서의 개인키를 고객사 밖으로 내보낼 수 없는 단계에서는 개인키 연산만 에이전트에 두고 기관별 서명 로직을 서버에 남겼습니다. 전체 인증·조회 로직을 설치형으로 옮기는 구현안에서는 보호할 책임을 native 바이너리 안에 모았습니다. 두 단계의 산출물 경계와 로컬 통제 검증은 별도 기술 사례로 분리했습니다.