연동 AES 암호화 방식(GCM) 적용 가능 여부 문의
안녕하세요.
현재 LG U+ 결제 연동 과정에서 요청 payload를 AES 방식으로 암호화하여 전송하고 있으며,
기존 AES/CBC/PKCS5Padding 방식을 사용하고 있습니다.
사내 보안 점검(AppScan) 결과, AES/GCM/NoPadding 방식 사용을 권고받아
암호화 모듈 변경을 검토 중입니다.
아래 API 및 MID 환경에서 AES/GCM 방식 적용이 가능한지 확인 요청드립니다.
API URL: https://upaynowapi.tosspayments.com/2/v1/
MID: AESTURA365
현재 방식: AES/CBC/PKCS5Padding
전환 검토 방식: AES/GCM/NoPadding
전송 데이터: JSON 요청 파라미터 전체 암호화 후 Base64 인코딩
확인 요청 사항:
해당 API가 AES/GCM 암호화 방식을 지원하는지
지원한다면
권장 IV(Nonce) 길이
TagLength (기본 128bit 사용 가능 여부)
암호문 전송 구조(IV + Cipher + Tag) 규격
만약 GCM을 지원하지 않는다면
CBC 방식 유지 시 필요한 보완 방법 또는 예외 처리 가능 여부
보안 기준 준수를 위해 정확한 암호화 방식 확인이 필요한 상황입니다.
확인 부탁드립니다.
감사합니다.
4 Replies
⏳ 잠시만 기다려주세요! 곧 답변드리겠습니다
오류 문의일 경우 아래 정보를 미리 전달해주시면, 빠른 답변에 도움이 됩니다.
- 주문번호(orderId) :
- 문의 내용 :
(문제가 발생한 이미지나 전체 결제흐름 동영상을 첨부해주시면 빠른 분석을 받으실 수 있습니다.)
* 계약관련 내용은 1544-7772로 문의주세요.
* 주말/공휴일에는 답변이 늦을 수 있어요.
해당 방식은 제공하지 않고 있습니다. https 에서 사용하는 TLS v1.3 사용에도 보안 이슈가 있으신건가요/
소스 기준으로 앱스캔 보안 취약점이 확인되어 문의드렸습니다.
답변 확인 감사합니다.
AES/GCM 방식은 제공하지 않으신다고 하여,
기존 AES/CBC/PKCS5Padding 방식은 유지하되
내부 보안 점검(AppScan)에서 지적된 IV 고정 사용 문제를 해소하기 위해
IV를 요청마다 랜덤 생성하는 방식으로 수정하여 대응하겠습니다.
해당 변경은 암호화 알고리즘(CBC)은 그대로 유지하며,
표준 CBC 운영 방식에 맞추어 랜덤 IV 사용만 적용하는 것으로
API 프로토콜에는 영향이 없음을 확인했습니다.
추가적으로 검토가 필요한 사항이 발생할 경우 다시 문의드리겠습니다.
감사합니다.
❤️ 기술문의 경험이 어떠셨나요?!
간단히 코멘트 남겨주세요! 제품 발전에 큰 힘이 됩니다.