다중_채널_기반_오픈_API.pdf

• 논문 자체 요약
  • 금융권 표준오픈 API는 상호인증 과정의 핵심API인증키보호를 위해, 결제 관련 핀테크기업이추가보안기술을 개발/적용 하는것을 권고하고 있다. 기존 오픈 API관련 연구의 문제점과취약점을 추가 분석하고, 이기종플랫폼의 호환성을 고려하여 설계되었다. 기존 보안프로토콜의 단일 채널에 추가 보안 채널을 분리하여 은닉하는 방법을 적용했다. 성능분석결과 다중채널의 통신세션 양방향 안전성과 강화된 인증키의 중간자공격 안전성을 확인하였으며, 다중세션에서 지연시간의 연산성능(1초이하)을확인하였다.

주요 내용

• 금융기관의 공통점
  • 데이터에 대한 적절한 보호, 이용 편의성, 데이터 투명한 관리 등을 위해 정보 요청/제공 방식이 표준화된 오픈 API를 활용
• 새로운 환경 등장으로 금융 및 결제 시장은 보안 인프라 및 개인정보 관리 이슈가 발생
  • 데이터 통합 서비스 구조 특성상 기존 개인정보 보호법과 다른 성격의 정책 반영
  • 금보원 오픈API 보안 점검 가이드라인은 표준 API 보안 강화를 위해 각 사업자들에게 추가적인 보안 기술 개발/적용을 권고 중
• 해당 논문은 표준 API 인증키 보호를 강화하는 다중 채널 기반 보안 프로토콜 제안
• 기존 핀테크 앱의 서비스 방식
  • 금융권 오픈 API는 사용자의 중요정보에 대한 정보를 통합 활용하기 떄문에 데이터 유출이나 변조에 취약

• 금보원은 개발보안/암호통제/접근통제/시스템 보안 위협 등 이용기관과 핀테크 서비스에 대한 보안 요구 사항을 정의

  • 개발 보안 요구사항 핵심 요소는 오픈 API 프로토콜의 인증 및 접근키의 보호화 접근 권한 관리
  • 표준 오픈 API 키는 OAuth2를 사용하여 인증과 권한인가 기능을 수행
  • 인증방식은 인증 코드 권한 부여(Authorization Code Grant Type)방식 채택

  

  <aside> 💡 OAuth2 보안 프로토콜은 기관, 사용자, 자체 인증 모두 인증토큰(Access Token)을 사용

  </aside>

• 오픈 API 보안은 OAuth2 프로토콜을 중심으로 위협 영역을 분류하면 크게 두 가지 영역으로 나뉨

  • 사용자의 내부 응용 소프트웨어와 핀테크 기업 사이의 통신구간
    • 실제 사용자의 핀테크 앱은 핀테크 업체 사이의 통신 구간의 안정성이 확보되어야 함
    • 해커는 세션 생성 이후 정상적인 API 접근키와 인증키를 획득하고 재사용하여 인증서버의 권한을 획득하는 것이 일반적인 해킹 시나리오

  

• 현재 핀테크 서비스는 전용 APP 내에서 비밀번호, 지문 생체정보, OTP 기능을 제공하는 형태로 구현

• 위 논문에서 주장하는 다중 채널 방식

  • ①② 서비스 접근 및 URL 검사 : 핀테크 서비스 접근과 함께 기존 알려진 취약 대응책으로 URL 검사 부분 표기. 모든 프로토콜 동작은 기본적으로 TLS 기반 암호화 프로토콜 사용
  • ③ 로그인요청 : 초기 생성된 고유 식별자(ID)를 핀테크 서비스를 거쳐 인증 서버로 전송
  • ④ 로그인 : OAuth 표준 보안 프로토콜은 ID, PASSWORD 등 다양한 형태의 식별 파라미터를 전송하여 사용자 인증 수행
  • ⑤⑥ 독립 채널 상호인증 : 사전(가입)에 교환된 공개키 쌍을 사용하여 사용자의 핀테크 서비스 간에 상호 인증 수행. 기존 프로토콜은 URL 기반의 통신 수행. 새로 추가된 독립세션은 핀테크 월렛 내부 TCP 통신으로 상호인증 구현
  • ⑦⑧ 인증 코드 교환 및 암호화 : 정상적인 인증 코드 교환. 비밀 식별자(Secret ID)를 생성하여 두 채널 사이의 암호화 파라미터 사용
  • ⑨ 접근 토큰 교환 및 검증 : 주기적으로 외부 보안 채널에서 토큰을 검증
  • ⑩ 정상 로그인 후 서비스
  • ⑪⑫ 서비스 요청/응답 : 초기 과정에서 발급받은 오픈 API 접근키를 이용하여 서비스

• 다중 채널 기반 프로코로 과정의 특징
  • 기존 오픈API 프로토콜의 TLS 암호화 채널 전체가 안전하다고 가정하기 힘듦
  • 오픈 API 프로토콜에서 생성된 보안 세션을 독립된 보안 세션으로 안정성 강화
  • TLS의 경우 서버의 보안 설정에 따라 암호 알고리즘 설정이 다르게 변하지만 TLS1.3버전으로 강제(비교적 안전)
  • 초기 세션에서 생성된 접근 토큰 내부에 Secret ID를 포함하기에, 토큰이 주기적으로 갱신될때마다 독립된 채널에서 상호 검증 수행

• 보안 검증
  • 다중세션읜 양방향 안전성 : 초기 세션 1개의 접근 키에 대해 2개의 세션 키를 생성하여 검증
  • 접근 키에 대한 안전성 : 접근 키 내부에는 공개키 기반으로 생성된 Secret ID를 포함
    • SSL/TLS 암호화가 무력화된 경우 Secret ID를 추가 계산
  • 중간자 공격에 대한 안전성 : 다중 세션은 기존 중간자 공격에 방어하기 위한 다른 보안 채널을 추가 검증하는 방식
• 현재 금융권에서 안전성을 검증받은 PKI 인프라는 대부분 암호화에 X.509 표준 RSA 알고리즘 사용
  • 오픈 플랫폼/오픈API의 활성화는 생체인증이나 RSA 이외 안전한 프로토콜과 함꼐 새로운 알고리즘 조합이 요구될 것으로 예상
    • 거기에 맞춰 제안한 논문