일본 및 한국 통신사 LTE 주파수 정리, 내 폰을 가져가서 쓸 수 있을까?

이와 관련하여 마토메1류가 무척 흔하게 널려 있는 게 사실이지만, 사실은 본인이 검색하기 귀찮아서 남기는 내용입니다.

주파수 대신 이해하기 편리한 밴드로 정리해둬야 호환성에 대한 혼란을 막을 수 있습니다. 그래서 되도록이면 MHz 단위는 생략하고 주파수의 별명인 밴드로만 적어둡니다.

일본 주파수 정리2

NTT Docomo

도코모는 일본 내 최대의 통신사입니다. 공기업이었던 시절도 있어서 공기업에 뿌리를 두고 있는 KT랑 가장 많이 비교됩니다. 역시 가장 많은 이용자를 확보하고 있는데, 한국은 한국이동통신이라는 주식회사를 근간으로 둔 SKT가 더 먼저 이용자 확보를 시작한 역사로 인해 최대 이용자 통신사는 KT가 아니지요.

KT 사용자는 Docomo에서 로밍 요금제를 사용할 수 있습니다.

  • 밴드 1 (2.1GHz): 글로벌 주파수3
    • FDD 주파수 중 빠른 속도를 보이며, 비교적 전국적인 커버리지를 갖고 있다고 합니다.
  • 밴드 3 (1.8GHz): 글로벌 주파수
    • 도쿄, 나고야, 간사이 중심으로만 활용되는 주파수라고 합니다.
  • 밴드 19 (800MHz) ⊃ 밴드 6 (밴드 5,6,18,19를 포함함): 플래티나 밴드, 속도는 느리지만 지방에서 기지국을 적게 세우기 위해 사용.
    • 플래티나 밴드4
    • 타 밴드에서 커버되지 않는 지하 음영 지역에서 유용하게 쓰입니다.
  • 밴드 21 (1.5GHz)
    • 일본에서만 쓰이듯이 하는 대역으로, 일부 지역에서 보완적 역할만 합니다.
  • 밴드 28 (700MHz): 글로벌 주파수
    • 플래티나 밴드
    • 2019년 3월부터 트래픽 용량 확보를 위해 활용되기 시작한 추가 주파수 대역입니다.
  • 3.4GHz 추가 할당 완료
  • 밴드 42 (3.5GHz, TDD)
    • 캐리어 어그리에이션으로을 위한 대역으로 전체 주파수 대역 중 가장 빠른 속도를 자랑합니다.
    • 보조 주파수지만 단말기가 지원하면 품질이 크게 좋아질 것으로 기대됩니다.

Softbank

가입자 수는 가장 적지만, 나름대로 수요를 확보하고 있습니다.

SKT 사용자는 Softbank에서 로밍 요금제를 사용할 수 있습니다.

  • 밴드 1 (2.1GHz): 글로벌 주파수
    • 소프트뱅크의 주력 주파수
    • 고속 통신 담당, 넓은 커버리지
  • 밴드 3 (1.8GHz): 글로벌 주파수
    • 구 EMobile (현 Y! Mobile)을 인수합병하여 얻은 주파수
    • 당시 주력이었던 만큼 꽤 고속 통신 가능
  • 밴드 8 (900MHz)
    • 플래티나 밴드
    • 지하 음영 지역에 유용하게 활용됩니다.5
  • 밴드 11 (1.5GHz)
    • 실험적 성격의 주파수로 중요도가 높지 않음
  • 1.7GHz 추가 할당 완료
  • 밴드 28 (700MHz): 글로벌 주파수
    • 플래티나 밴드
    • 커버리지가 넓지 않아 중요도가 높지 않음
  • 밴드 41 (2.5GHz, TDD)
    • AXGP라고 불리는 모바일 WiFi 라우터 및 Softbank Air에 사용
    • 5G 활용을 위해 서비스 중단일 것으로 알려져 있습니다.
    • 망 재판매 사업자인 MVNO에게는 공개되지 않은 주파수입니다.
  • 3.4GHz 추가 할당 완료
  • 밴드 42 (3.5GHz, TDD)
    • 속도가 빠른 주파수 대역
    • 캐리어 어그리에이션을 진행중이지 않은 소프트뱅크에겐 크게 중요하게 여겨지지 않습니다.

KDDI au

CDMA(JCDMA)로 가장 오래 버틴 통신사가 바로 KDDI입니다. LG U+와 공통점이 많은데, 통신 세대가 올라가면서 CDMA를 과감히 버리고 LTE에 올인하는 점이 닮았습니다. 그리고 WiBro 기술인 WiMax II를 본격 상용화한, 세계에서 몇 안 되는 통신사이기도 합니다. 이로 인해 한국에서 온 여행자들 사이에선 휴대용 와이파이 모뎀 서비스 통신사로 기억하는 사람들도 적지 않습니다.

LG U+ 사용자는 기본적으로 KDDI에서 로밍 요금제를 사용할 수 있습니다.

  • 밴드 1 (2.1GHz): 글로벌 주파수
    • au의 주력 주파수입니다. 또다른 주력 밴드 18과 더불어서 폭넓은 커버리지를 제공합니다.
  • 밴드 11 (1.5GHz)
    • 실험적인 주파수로 중요도가 높지 않습니다.
  • 밴드 18 (800MHz)
    • 플래티나 밴드
    • 주력으로 꽤 넓게 설치되어 있으며, 지하 음영 지역에서 활용되는 주파수입니다.
  • 밴드 26 (800MHz) (밴드 19를 포함)
    • 밴드 18과 유사한 특성
  • 밴드 28 (700MHz): 글로벌 주파수
    • 실험적 주파수인데, 앞으로 활용할 것으로 보입니다.
  • 밴드 41 (2.5GHz, TDD): WiMax에 사용 (별도 상품)
    • 고속통신 단말기, 라우터용
  • 밴드 42 (3.5GHz, TDD)
    • 캐리어 어그리에이션용 대역
    • LTE 속도 개선용

Rakuten Mobile (추가 내용)

2019년 10월부터 상용 서비스에 들어가는 라쿠텐 모바일은 원래 MVNO 통신사로, 한국에서는 알뜰폰 사업자에 해당했습니다. 도코모 망을 빌려쓰다가 이제 제 4 통신사로 메이저 업계에 참전합니다. 타사와는 반대로 5G에 4G를 얹어서 서비스하는 차세대 통신망을 지향하고 있습니다. 현재 할당 받은 주파수는 아래와 같은 단 한 개로 알려져 있습니다.

  • 1.7GHz 추가 할당 완료

다만, 3G를 건너뛰고 LTE부터 시작한 au와 제휴를 통해 자사의 결제 시스템, KDDI의 통신망 로밍을 제공받게 되면서, 공급받는 단말기는 au가 지원하는 주파수를 덩달아 지원하도록  할 것으로 예상됩니다.

한국 주파수 정리

SKT

밴드 3, 밴드 7에 넓은 대역폭을 갖고 있고, 밴드 1과 밴드 5는 보조하고 있습니다. 2016년 경매로 밴드 1은 LG U+로 일부 넘어갔습니다.

  • 밴드 1 (2.1GHz): 2016년 일부 반납. WCDMA HSPA와 같은 주파수, 일부 전환. 글로벌 주파수.
  • 밴드 3 (1.8GHz): 글로벌 주파수.
  • 밴드 5 (800MHz): 황금 주파수. 글로벌 대역 아님.
  • 밴드 7 (2.6GHz): 글로벌 주파수.

KT

2016년의 경매로 밴드 3의 대역폭이 더 늘어났고, 밴드 8이 보조하고 있습니다.

  • 밴드 1 (2.1GHz): WCDMA HSPA 일부 전환 예정. 글로벌 주파수.
  • 밴드 3 (1.8GHz): 글로벌 주파수. CDMA PCS 대역 전환하여 사용. 주력 주파수.
  • 밴드 8 (900MHz): GSM 변환 대역으로 각광받았으나 뜨뜻 미지근한 주파수. KT 사용자는 건물내 등 약전계에서 이 주파수가 잘 잡히는 경향이 있음.
  • 밴드 26 (800MHz): 인수로 인해 어부지리로 얻은 주파수. 기지국 없음. 호환성 낮음. 활용 계획 없음.

LG U+

SKT에서 긁어모은 밴드 1과 밴드 7 모두 넓은 광대역 밴드만 모아서 쾌적함을 자랑하고 있습니다.

  • 밴드 1 (2.1GHz): WCDMA HSPA와 같은 주파수. 글로벌 주파수.
  • 밴드 5 (800MHz): VoLTE 통화에 활용하는 주력 주파수.
  • 밴드 7 (2.6GHz): LTE8을 구성하는 넓은 대역폭.

슬슬 TDD 주파수에도 눈을 돌려줬으면 좋겠네요. 요즘 폰들, TDD도 자연스럽게 지원하거든요. WiBro보다 더 안정적인 인터넷 환경이 펼쳐질까 주목됩니다.

FAQ

밴드가 호환되는데 왜 작동하지 않는가?

국내 휴대폰은 상당수가 별도 설정을 필요로 할 수 있습니다. 서비스 모드에 들어가서 통신망의 밴드를 모두 켜놨는지, 선호 주파수를 무엇으로 해두었는지에 따라 의도치 않은 동작을 할 수 있습니다.

과거에는 APN이 올바르지 않아서 안테나 아이콘은 제대로 뜨는데 인터넷 사용이 불가했던 경우가 많았습니다. 그러나 최신 단말기들은 주요 통신사의 APN을 미리 내장하고 있어서 유심 인식만으로 통신에 불편함은 없어지게 되었습니다.

그럼에도 VoLTE와 같은 부분이 발목을 잡게 되었지요…

VoLTE 사용은 불가능한가?

KDDI au는 타사와 같은 3G 통신망이 없기 때문에, VoLTE가 제대로 설정되어야만 통화가 가능합니다. 대부분 단말기 제조사에서 로밍은 미리 입력해놓은대로 작동하기에 별도 설정 없이 통화가 되지만, 로밍이 아닌 로컬 연결로는 이 설정이 활성화되지 않는 겨우가 많습니다.

au에 대해서는 VoLTE를 배려하여 주요 제조사에서 미리 설정을 넣어두어 불편이 없을 수도 있습니다.67 그러나 그 외의 단말기에서는 설정이 가능할 수도, 원천적으로 기능이 없어서 불가능할 수도 있으므로 골치가 아픕니다. 뒤늦게 개통을 취소할 수도 없는 노릇이니까요.

거꾸로 일본의 타사도 VoLTE를 제공하는데, 이 옵션은 더 까다롭습니다. 3G 통화가 되니까 VoLTE는 단말기 제조사에서 더욱 등한시하기 때문입니다. 성공한 사람이 있다면 그 강좌를 따라하면 될 가능성도 있으나, 별 명시가 없으면 VoLTE를 없는 기능으로 보는 게 더 낫습니다.

MVNO는 어떤가요?

한국에서는 알뜰폰이라고 합니다. 망 재판매 사업자는 주요 통신사에서 일정 가입자 회선을 미리 사들여서 저렴한 가격에 서비스를 하죠. 지금까지는 특정 통신사 망을 쓰는 알뜰폰 업체로 간단히 분류 가능했는데, 요즘 헬로우 모바일 같은 곳은 KT와 SKT 양쪽을 서비스하고 있습니다. 가입시 실제 망 사업자를 알아보는 것이 유일한 방법입니다. 고객센터 연결이 불편하다는 점 탓에, 단말기 호환 문제가 발생할 경우 해결에 오래걸릴 수 있으니 주의해야 합니다.

일본에서 格安(가쿠야스)SIM이라고 불리는데, 요즘 필수 덕목이 되고 있죠. 새로 폰을 개통하는 사람들 중에 조금이라도 알아보신 분이라면 메이저 통신사에서 직접 개통하는 것이 너무나 비싸다는 걸 잘 아실 겁니다.

일본에서는 각 MVNO 상품에 코스가 명시되어 있습니다. A코스, D코스, S코스… 눈치채셨겠지만, au, docomo, softbank를 지칭하는 것이죠. 같은 요금제도 코스를 어떻게 구성하냐에 따라 제약 사항과 요금 자체가 크게 달라집니다. 그리고 당연히 선택한 망 통신사의 기술적 특징을 그대로 따라갑니다. 지원 단말기의 경우 망 통신사에서 제공하는 VoLTE도 똑같이 쓸 수 있다고 설명하고 있으니 믿어봐도 괜찮겠습니다.

정리

요즘 폰들 사면 1, 3, 5, 7, 8, 11, … 이런 식으로 지원하는 밴드 표기를 한 곳이 많습니다. 그런 제품들을 보면서 자연스럽게 어떤 통신사에서 사용이 가능할지 빠르게 판별하는 게 필요합니다.

사족

글로벌 주파수는 FDD 1, 3, 7, 28 / TDD 38, 40입니다.

Asus Zenfone 5z 개봉기

ASUS가 폰을 만듭니다.

그런 사실을 어째서인지 한국 사람들만 잘 모르고 있습니다. 당연한 일입니다. 출시한 적이 없는 해외폰이니까요.

하지만 저는 과거의 ASUS가 만든 폰을 직접 사용해본 적도 있습니다. 그건 바로 Asus Zenfone 5입니다.

그 때의 사용기를 어딘가 적진 않았지만, 지금 사진을 보니 참으로 각진 기묘한 디자인입니다.

뒤쪽 덮개를 열 수 있는데 배터리는 슬쩍 보임에도 아예 분리할 수 없게 고정되어 있었던 게 특징입니다.

또 듀얼심인데 3G 대응, 나머지는 무조건 2G(GSM)만 가능하여서, 3G HSPA+ 계열만 있던 한국에선 듀얼심으로 사용할 수 없었습니다. 한국에 GSM이 없거든요.

2014년 당시엔 괜찮았지만, LTE 시대에 들어오면서 GSM도 세대가 2단계 (또는 그 이상) 뒤쳐지다보니, 서비스를 중단하는 곳도 늘고 주파수는 실시간으로 용도 전환이 되며 입지가 좁아지고 있습니다.

그래서 듀얼심에 대한 환상도 와르르 무너졌던 기억이 있습니다.

LG Optimus LTE, Galaxy S3, ASUS Zenfone 5 (2014) 벤치마킹

Intel Atom Z2580 칩셋을 사용하고 있는데, x86에 arm 에뮬레이팅이 내장되어 있습니다.

그럼에도 일부 게임이 호환이 안 된 적도 있던 것 같습니다. 애매한 성능에 애매한 배터리, 적지 않은 발열로 요약되는 경험이었죠. 왜 가만히 냅둬도 혼자서 가끔씩 뜨겁게 불타올랐던 걸까 지금도 모르겠습니다.

깨알같이 5GHz WiFi 미지원도 단점이었죠.

ASUS Zenfone 5를 써봤는데, 4년 후 새로 산 폰도 ASUS Zenfone 5라니

제가 산 제품은 정확하게는 끝에 Z가 하나 더 붙은 건데, 이건 AP 성능 차이로 인한 라인업의 다른 것일 뿐, 실제 메인 스트림은 둘 다 같은 제품명입니다.

대략 정신이 멍해지는 네이밍 센스랄까 꼬여버린 족보라고 할 수 있겠습니다.

그래서 지금도 구글링하면 Asus Zenfone 5 (2014), Asus Zenfone 5 (2018) 이렇게 나뉩니다.

이름은 같지만, 많은 것이 달라졌습니다.

험난한 배송 과정을 드러내는 외부 박스를 벗기니 Zenfone 5z의 길쭉하고 작은 박스가 드러납니다.

박스를 위로 벗기면 사진을 좋아한다는 ASUS의 주장이 담겨있습니다.

기본으로 젤리케이스 투명을 하나 끼워줍니다. 중국산 폰은 빌트인 케이스 하나씩 끼워주는게 서비스인 것 같습니다.

그런데 ASUS는 대만산인데…. 흠…

심 트레이 클립도 나름대로의 스타일을 갖고 있는 것 같습니다.

그래서 잃어버리지 않으려고 하는데, 쉽지 않겠어요.

실리콘 케이스와 보증 서류를 치우면 비닐로 한꺼풀 덮여있는 본체가 드러납니다.

세로로 긴 폰이 불투명한 비닐로 포장되어 있습니다. 전원 버튼을 못 찾을까봐 비닐에 위치가 하이라이트되어 있습니다.

비닐을 벗기면 당연히 없어지겠지요.

상자의 아랫 부분을 열어 보면 프리볼트 0.5A 입력의 충전기(출력 5V/2A+9V/2A), 데이터 케이블, 이어폰, 이어폰 커널이 있습니다.

비닐을 벗기고 뒷면을 보면 빛이 납니다. 강화유리로 한꺼풀 덮기라도 했는지 미끈거리며, 지문은 마구마구 묻어납니다.

케이스가 없으면 나중에 허옇게 지문이 얼룩져 있어서 꼴보기 싫어하는 사람도 많을 것 같습니다.

가운데 LG 폰처럼 지문 인식 영역이 있습니다. 전에 쓰던 폰도 LG V20이라서 똑같은 위치에 지문 인식이 있었는데, 어느쪽이든 검지를 갖다대어 인식하기 편리합니다.

다만 차이가 있다면 전원 버튼 등의 역할을 하지 않는 고정된 영역에 불과하다는 것입니다.

버튼 같이 생겼지만, 안타깝게도 눌리지 않아요.

상단에는 별 것이 없습니다. 구멍이 하나 있는 건 통화시 배경 소리 녹음용 보조 마이크 같습니다.좌측면에도 별 것이 없습니다. 보조 마이크가 두 개라고 하던데, 여기에도 구멍이 하나 더 있긴 합니다.

유심을 삽입할 수 있는 트레이와 핀 구멍도 있습니다. 하이브리드 듀얼심이라 SIM 2에 MicroSD나 두 번째 SIM 카드 둘 중 하나만 넣을 수 있습니다. 보조 장비를 구매하여 SIM 카드를 외부로 연장시키는 도구를 쓰면 메모리 카드와 SIM 카드 두 가지를 활용할 수 있다고 하더군요.하단은 좌측부터 3.5파이 이어폰 단자, USB C-Type 포트, 우측에 모노 스피커가 있습니다.

그런데 특이하게도 수화 스피커로도 평시에 소리를 스테레오로 내고 있습니다. 대칭이 아닌 기묘한 스테레오 음향인 셈인데, 들어줄만 합니다.우측에는 위부터 볼륨, 전원 버튼이 간격을 두고 있습니다.

예나 지금이나 무게감 있는 로고명이라고 생각합니다. Powered by Android 라는 문구가 앞에 빠르게 지나갑니다. 부팅 속도는 결코 느리지 않은 편이에요.

알고보니 램 보존 부팅을 오래전부터 하던 제조사더군요. 최대 절전 모드와 유사한 방식이라고 합니다.

안드로이드 오레오 8.1의 순정이 어떠한지 잘 모르겠지만, 깔끔하게 다듬어진 UI로 보입니다. 당당히 한국어도 지원하고 있으며, 번역에 거슬리는 부분은 크게 드러나지 않습니다.

한국에 팔아도 욕먹지는 않겠어요.

아… 저런 오타는 이해해줘야 할까요. 긹! 이전 장치에 옮긴다는 표현도 이상하긴 하네요.

이 앱은 기존 폰에도 설치해서 Wi-Fi Direct로 연결하여 데이터 및 APK를 그대로 전송할 수 있습니다.

그러나 구글 백업의 복원과 동시에 진행하지 않기를 권합니다. 같은 앱 패키지를 깔 때 충돌나서 앱 이동 설치 작업이 도중에 중단되고 급기야 Wi-Fi Direct가 끊겨서 처음부터 다시 해야 합니다.

물론 옮겨진 부분까지는 그대로 넘어오기 때문에 남은 것만 선택하고 진행하면 되지만, 그게 선택이 날아가서 도중에 그만두면 다시 시작하기가 쉽지가 않아요.

앱 데이터가 옮겨지지 않는 것 같고 요즘 앱들이 자체 클라우드 로그인을 하면 하지, 백업을 대체로 거부하기 때문에 그냥 플레이스토어 들어갈 수고를 던다는 의미밖에 없긴 합니다.

기존 폰의 내부 저장소의 폴더를 싹 긁어올 수 있어서, 다운로드 폴더에 한가득 짐을 짊어지고 계신 분들도 기존 폰에서 유실되는 자료 없이 옮길 수 있다는 건 큰 장점입니다.

갤럭시처럼 USB Direct 케이블 연결도 지원하면 나무랄 데가 없겠어요.

런처 사진을 찍을까 했지만, 개봉기의 마무리는 게임 실행으로 끝냅니다.

아쉽게도 이 앱은 18대 9의 초와이드 화면을 지원하지 못해 오른쪽에 검은 레터박스가 드러나네요.

게임 및 퍼포먼스, 내부 소프트웨어에 대한 이야기는 다음편에 이어서 할까 합니다.

[번역글] 2. 인증서 투명성 작동 방식

이전글: 1. 인증서 투명성 (Certificate Transparency) 개요

인증서 투명성이 작동하는 방식

인증서 투명성은 세 가지 기능을 현행 SSL 인증서 시스템에 추가합니다.

  • 인증서 로그
  • 인증서 감시자 (monitors)
  • 인증서 감사자 (auditors)

이들 기능 구성 요소는 서비스를 보완적으로 감시하고 감사할 수 있는 분리된 소프트웨어 모듈을 나타냅니다. 현행 SSL 인증서 시스템을 대체하거나 교체하는 것은 아닙니다. 실제로, 이들 구성 요소는 클라이언트가 도메인을 검증하고 서버와 안전한 연결을 맺는 기본적인 신뢰 체인 모델을 바꾸는 것이 아닙니다. 대신에, 전체 SSL 인증 시스템에 대한 공개적인 관찰과 조사 지원을 제공하는 신뢰 체인 모델로 강화합니다.

기본 로그 방식

인증서 투명성 시스템 중심에는 인증서 로그가 있습니다. 인증서 로그는 SSL 인증서에 대한 자료를 유지하는 간단한 네트워크 서비스입니다. 인증서 로그는 세 가지 중요한 특징이 있습니다.

  • 추가만 가능: 인증서는 로그에 추가될 수만 있습니다. 인증서는 제거되거나, 수정되거나, 로그에 일괄 삽입되지 않습니다.
  • 암호화 보장: 로그는 Merkle Tree Hash라고 하는 특별한 암호화 방식을 사용하여 조작과 오동작을 방지합니다.
  • 공개 감사 가능: 누구든지 로그를 조회하고 올바르게 동작하는지 검증하고, SSL 인증서가 적절하게 로그에 추가되었는지 검증할 수 있습니다.

로그 수는 많을 필요가 없습니다. 충분한 수의 로그가 있으므로 로그 실패나 일시적인 접속 불가가 문제가 되지 않습니다만, 감시하기에 어려울 정도로 많아지지 않게 하세요. 이를테면, 10개보다 많지만 1000보다 적게 하세요. 각 로그는 다른 로그와 독립적으로 작동합니다. (즉, 로그 사이 자동 복제가 없다는 것입니다)

추가만 가능한 로그는, 로그가 손상되지 않았고, 로그 작성자가 로그에서 어떤 인증서도 제거하거나 변경하지 않았다는 것을 증명하는 특별한 암호화 해시를 사용할 수 있게 합니다. 이 특별한 해시(Merkle Tree Hash로 알려짐)는 감사자가, 누군가 로그를 분리했거나 오래된 인증서를 로그에 삽입하였는지 탐지할 수 있게 합니다. 더 자세한 정보는, 로그가 작동을 보장하는 방법을 보세요.

모든 인증서 로그는 반드시 (다른 것과 함께) URL과 공개키를 송출해야 합니다. 누구든지 HTTPS GET과 POST 메시지를 통해 로그와 상호작용할 수 있습니다.

기본 로그 작동

누구든지 인증서를 로그에 전송할 수 있지만, 대부분의 인증서는 인증 기관과 서버 관리자에 의해 전송될 것입니다. 누군가 올바른 인증서를 로그에 전송하면, 로그는 인증서를 로그의 어떤 시간에 등록했는지 간단히 보증하여 알려주는, 서명된 인증 타임스탬프(SCT)로 응답합니다. 이 시간은 최대 병합 지연(MMD)로 알려져 있습니다.

MMD는 합리적인 시간 내에 로그 서버가 인증서를 로그에 추가하도록 하며 로그가 복원력과 가용성을 위해 분리된 서버 집합을 실행할 수 있도록 허용하면서 인증서의 발급 또는 사용을 차단하지 않습니다. SCT는 인증서의 수명동안 인증서와 함께 제공됩니다. 특히, TLS 서버는 TLS 핸드쉐이크가 일어나는 동안 SCT를 인증서와 함께 전송해야 합니다.

인증서 투명성은 SCT를 인증서와 함께 제공하는데 세 가지 방법을 지원합니다. 각각은 아래에 설명되어 있습니다.

X.509v3 확장

인증 기관은 X.509v3 확장을 사용하여 SCT를 인증서에 첨부합니다. 1번 그림은 이 방식을 나타냅니다. 인증 기관은 로그에 사전 인증서를 전송하고, 로그는 SCT를 반환합니다. 인증 기관은 이어서 SCT를 사전 인증서에 X.509v3 확장으로서 첨부하고, 인증서를 서명하고, 인증서를 서버 운영자에게 제공합니다.

이 방식은 서버 변경을 필요로 하지 않으며, 서버 관리자가 SSL 인증서를 기존에 해오던 방식과 똑같이 관리할 수 있도록 합니다.

TLS 확장

서버 운영자는 SCT를 특별한 TLS 확장(그림 2 참고)을 통해 전달할 수 있습니다. 이 경우, 인증 기관은 인증서를 서버 운영자에게 발급하고, 서버 운영자는 인증서를 로그에 전달합니다. 서버 관리자에게 전달되고, 서버 관리자는 signed_certificate_timestamp 타입의 TLS 확장을 사용하여 TLS 핸드쉐이크 도중에 클라이언트에 SCT를 제공합니다.

이 방식은 인증 기관이 SSL 인증서를 발급하는 방식을 그대로 유지할 수 있게 합니다. 그러나, TLS 확장을 수용할 수 있도록 서버를 변경해야 합니다.

OCSP 스테이플링

서버 운영자는 SCT를 온라인 인증서 상태 프로토콜(OCSP) 스테이플링을 사용하여 전달할 수도 있습니다 (그림 2 참조). 이 경우, 인증 기관은 로그 서버와 서버 운영자 양쪽에 동시 인증서를 발급합니다. 서버 운영자는 OCSP 쿼리를 인증 기관에 보내고, 인증 기관은 SCT와 함께 응답하여, 서버가 TLS 핸드쉐이크할 때 OCSP 확장을 포함할 수 있게 합니다.

이 방식은 SCT를 비동기적으로 얻을 수 있으므로, 인증 기관이 SCT에 대한 관리 책임을 가질 수 있게 하면서도 인증서 발급에 지연을 일으키지 않습니다. 그러나, OCSP 스테이플링을 할 수 있도록 서버를 수정해야 합니다.

기본 감시자와 감사자 작업

감시자는 출처가 불분명하거나 신뢰되지 않은 인증서, 비정상적인 인증 확장 또는 이상한 권한(예를 들어 인증 기관의 인증서)을 갖고 있는 수상한 인증서를 로그에서 감시합니다. 감시자는 로그에서 모든 로그된 인증서를 검증할 수 있습니다. 로그에 추가된 새로운 항목을 주기적으로 모두 가져오는 방식으로 이런 일을 할 수 있습니다. 그 결과, 대부분의 감시자는 감시하고 있는 거의 완전한 로그를 갖게 됩니다. 로그가 일정 시간 이상 오프라인이고, 감시자가 로그의 복사본을 갖고 있다면, 감시자는 읽기 전용 로그의 백업으로 동작할 수 있고, 로그를 쿼리하려고 하는 다른 감시자와 감사자에게 로그 데이터를 제공할 수 있습니다.

감사자는 로그의 전체 투명성을 검증합니다. 일부 감사자는 특정 인증서가 로그에 등장하는지를 검증할 수 있습니다. 로그 증명을 주기적으로 가져오고 검증하는 방식으로 진행합니다. 로그 증명은 로그가 올바른지를 증명하는데 쓰이기 위해 암호화된 해시로 서명됩니다. 모든 로그는 반드시 요청시에 로그 증명을 제공해야 합니다.

감사자는 로그의 오래된 항목에 새로운 로그 항목이 항상 추가된다는 것, 인증서가 손상되거나 중도에 추가 또는 삭제, 수정되지 않았다는 것을 검증하기 위해 로그 증명을 사용할 수 있습니다. 감사자는 또한 특정 인증서가 로그에 존재한다는 것을 보이기 위해 로그 증명을 쓸 수 있습니다. 이는 인증서 투명성 프레임워크가 모든 SSL 인증서를 로그에 기록해야 하기 때문에 특히 중요합니다. TLS 클라이언트가 (감사자를 통해서) 인증서가 로그에 없다는 것을 알게 되면, 로그가 올바르게 동작하지 않았다는 증거로 로그의 SCT를 사용할 수 있습니다. 자세한 정보는 로그 증명이 작동하는 방법을 살펴보세요.

로그 증명은 감사자나 감시자가 특정 로그에 대한 자신의 관찰 내용가 과거의 관찰 내용이 일치 하는지를 검증할 수 있게 하는 한편, 특정 로그에 대한 관찰 내용이 다른 감시자 및 감사자와 일치하는지 확인해야합니다. 이 검증을 하기 위해, 감사자와 감시자는 gossip 프로토콜을 통해 로그에 대한 정보를 서로 교환합니다. 이는 발췌된 로그를 탐지하기 위해 감사자와 감시자를 돕는 비동기적 의사소통 통로입니다.

일반적인 시스템 구성

인증서 투명성 프레임워크는 기존의 SSL 인증서 시스템에 감시자와 감사자의 특별한 구성이나 배치를 지시하진 않습니다. 다시 말해, 좀 더 흔히 이루어지는 특정한 구성이 있다는 것입니다. 일반적인 구성에서, 인증 기관은 감시자를 운영하고 클라이언트(브라우저)는 감사자를 구동합니다 (그림 3 참조). 이 구성은 감시자와 감사자에게 필요한 메시지 교환을 단순화하며, 인증서 감사자와 클라이언트가 고객과 사용자의 특정한 요구를 충족할 수 있는 감시 및 감사 시스템을 스스로 개발하게 합니다. 이 구성을 수행하는 과정 중 일부가 아래 서술되어 있습니다.

인증서 발급

인증 기관은 SCT를 로그 서버에서 취득하여, X.509v3 확장(이 과정에 대한 자세한 정보는 그림 1 참조)을 사용하여 SSL 인증서에 SCT를 통합합니다. 인증 기관은 이어서 (SCT가 첨부된) 인증서를 서버 운영자에게 발급합니다. 이 방식은 서버 업데이트를 필요로 하지 않고 (현재 X.509v3 확장을 지원하는 모든 서버), 기존의 SSL 인증서를 관리한 방식 그대로 서버 운영자가 인증서를 관리할 수 있게 합니다.

TLS 핸드쉐이크

TLS 핸드쉐이크 과정에서, TLS 클라이언트는 SSL 인증서와 인증서의 SCT를 수신합니다. 보통 TLS 클라이언트는 인증서와 서명 체인을 검증합니다. 거기에, TLS 클라이언트는 (다른 인증서가 아닌) 실제로 인증서가 발급된 SCT와 올바른 로그로 발급되었는지 SCT에 있는 로그 서명을 검증합니다. 불일치가 발견되면, TLS 클라이언트는 인증서를 거부해야 합니다. 예를 들어, TLS 클라이언트는 미래의 SCT 타임스탬프를 가진 모든 인증서를 기본적으로 거부해야 합니다.

인증서 감시

대부분의 감시자는 인증 기관에 의해 운영됩니다. 이 구성은 인증 기관이 더 효과적인 감시를 만들고, 자체적으로 표준과 요구 사항을 감시할 수 있도록 합니다.

인증서 감사

대부분의 감사자는 브라우저에 들어 있습니다. 이 구성에서, 브라우저는 주기적으로 SCT 배치를 통합된 감사 구성 요소로 전송하고, SCT(와 관련된 인증서)가 올바르게 로그에 추가되었는지를 질의합니다. 감사자는 이어서 비동기적으로 로그를 확인하고 검증을 행할 수 있습니다.

다른 시스템 구성

감시자와 감사자가 기존의 TLS/SSL 구성 요소와 긴밀하게 통합된, 위에 서술한 일반적인 구성 외에도, 인증서 투명성은 수많은 다른 구성도 지원합니다. 예를 들어, 감시자는 인증 기관과 서버 운영자를 대상으로 유·무료 서비스를 제공하는 단독 항목으로 구동될 수 있습니다 (그림 4 참조). 감시자는 Google, Microsoft, Yahoo 등 거대 인터넷 기업과 같은 서버 운영자에 의해 구동될 수 있습니다. 비슷하게, 감사자도 단독 서비스로 운영되거나, 감시자의 부가 기능으로 작동할 수 있습니다.

다음글: 3. 로그 증명의 작동 방식

[번역글] 1. 인증서 투명성 (Certificate Transparency) 개요

인증서 투명성 개요

구글의 인증서 투명성 프로젝트는 모든 HTTPS 연결에 쓰이는 주요 암호화인 SSL 인증서 시스템의 결함을 수정합니다. 이 결함은 인터넷 연결의 암호화된 연결의 효용성과 신뢰도를 약화시키고 도메인 인증, 양 끝단 암호화, 그리고 인증서 인증을 통해 구성된 신뢰 체인을 포함한 TLS/SSL 구조의 심각한 손상을 가져올 수 있습니다. 이를 확인하지 않고 방치하면, 이 결함이 웹 사이트 스푸핑, 서버 위장, 중간자 공격과 같은 광범위한 보안 공격을 가능하게 만듭니다.

인증서 투명성은 SSL 인증서를 거의 실시간에 가깝게 모니터링하고 감사할 수 있는 오픈 프레임워크를 제공함으로써 이러한 결함을 제거하는데 도움을 줍니다. 특히, 인증서 투명성은 SSL 인증서가 인증서 인증을 잘못 받았거나, 다른 정당하지 않은 곳에서 인증서 인증을 오남용하여 받았는지를 확인할 수 있게 합니다. 인증서 인증이 악의적인 사용자에게 넘어가서 잘못된 인증을 받았는지도 알 수 있게 합니다.

오픈된 공개 프레임워크이므로, 누구든지 인증서 투명성을 구동하는 기본 구성요소를 빌드하거나 접근할 수 있습니다. 이는 특히 도메인 소유자, 인증서 인증자, 그리고 브라우저 제조사와 같이, SSL 인증 시스템의 무결성과 상태를 유지하는 인터넷을 구성하는 인터넷 보안 관계자에게 유용합니다.

인증서 투명성을 더 알아보려면, 도입 문서를 읽어보세요. 이미 인증서 투명성의 기본 개념에 친숙하고, 상세 구현을 알아보려면 상세한 디자인 문서를 확인해보세요. 인증서 투명성 프레임워크를 구동하는 핵심 구성 요소를 빌드하는 방법에 대한 오픈 소스 프로젝트도 있습니다.

인증서 투명성이란 무엇입니까?

현대 암호화 기술 덕택에, 브라우저는 평소에 위조되었거나 가짜 SSL 인증서가 제공되는 수상한 웹 사이트를 판별할 수 있습니다. 그러나, 현재 암호화 기술은 잘못 발급된 인증서나, 위험해졌거나 악의적인 집단에 넘어간 인증 기관(CA)의 인증서가 제공되는 수상한 웹 사이트를 판별할 만큼 뛰어나진 않습니다. 이러한 경우, 브라우저는 인증서에 이상이 없다고 표시하게 되는데, 이에 따라 인증 기관이 멀쩡해 보이고, 방문하고 있는 웹사이트가 인증되었고 연결이 안전하다는 인상을 줍니다.

여기서 문제는, 현재로선 쉽고 효과적으로 SSL 인증서를 실시간으로 감사하거나 감시할 수 없어서, 이러한 오작동이 일어나게 되는 것이고 (수상한 경우 등), 의심스러운 인증서는 보통 탐지되지 않고 인증 철회는 수 주나 몇 개월 후에나 이뤄진다는 것입니다. 게다가, 이러한 종류의 SSL 오작동의 빈도가 더욱 늘어나고 있습니다. 지난 몇 년간 잘못 발급된 수많은 인증서가 합법적인 사이트를 가장하는데 쓰이고, 일부의 경우에는 수상한 소프트웨어를 설치하거나 무고한 사용자에게 침투하는데도 쓰였습니다.

한 가지 사례로, 저명한 네덜란드 인증 기관(DigiNotar)이 공격받았고, 해커는 CA 시스템을 사용하여 가짜 SSL 인증서를 발급할 수 있었습니다. 인증서는 이란에서 Gmail과 Facebook과 같은 수많은 사이트를 가장하는데 활용되었고, 이는 가짜 사이트 소유자가 무고한 사용자에게 침투할 수 있게 했습니다. 다른 사례는 말레이시아 소속의 인증서 기관(DigiCert Sdn. Bhd.)이 실수로 22개의 취약한 SSL 인증서를 발급하여, 웹 사이트를 가장하고 수상한 소프트웨어를 서명하는데 쓰였습니다. 그 결과, 주요 브라우저는 DigiCert Sdn. Bhd.가 발급한 모든 인증서에 대한 신뢰를 철회하였습니다.1

최근에, 거대한 U.S. 소재 인증 기관 (TrustWave)이 고객의 인증서 하나에 대한 하위 루트 인증서를 발급하여 고객이 내부 네트워크 트래픽을 관찰할 수 있게 했습니다. 하위 루트 인증서는 인터넷의 거의 모든 도메인에 대한 SSL 인증서를 발급할 수 있게 합니다. 비록 Trustwave는 인증서를 철회했고 고객에게 하위 루트 인증서를 더이상 발급하지 않지만, 인증 기관의 잘못에 의해 얼마나 커다란 결과를 낳게 되는지를 보여주는 사례입니다.

많은 경우에 잘못 발급된 인증서는 해커에 의해 심각한 결과를 초래할 수 있는 악의적인 공격을 하는데 사용되었지만, 일이 터진 후 후폭풍도 거대하고 위험합니다.

결국, 네덜란드의 인증 기관 인증서는 인증 철회되고, 인증 기관은 폐쇄되었습니다. 인증 철회 및 폐쇄는 네덜란드 사람들이 인증 기관의 SSL 인증서를 발급받은 정부와 개인 사이트를 접속하지 못하게 되는 여파를 만들었습니다.

사태 해결을 위한 인증서 투명성

인증서 투명성은 SSL 인증서 발급 유무를 도메인 소유자, 인증 기관과 도메인 유저에 의해 정밀하게 조사할 수 있도록 개방할 수 있도록 하여 이들 인증서 기반 위협을 대처하는 걸 목표로 합니다. 특히, 인증서 투명성은 세 가지 주요 목표가 있습니다.

  • SSL 인증서를 도메인 소유자를 드러내지 않고서는 인증 기관이 도메인 SSL 인증서를 발급하지 못하게 하거나, 어렵게 만듭니다.
  • 아무 도메인 소유자나 인증 기관이 인증서가 실수 또는 악의적으로 발급되었는지 여부에 대한 공개 감사 및 감시 시스템을 제공합니다.
  • 사용자가 가능한한 실수 또는 악의적으로 발급된 인증서에 속지 않도록 만듭니다.

인증서 투명성은 TLS/SSL 인증 시스템 감시와 특정 TLS/SSL 인증서 감사를 위한 공개 프레임워크를 만듦으로써 이러한 목표를 만족시킵니다. 이 공개 프레임워크는 아래 세 가지 주요 구성 요소로 구성되어 있습니다.

인증서 로그

인증서 로그는 암호로 보호되며, 공개적으로 감사되며, 인증서에 대한 레코드 추가만 가능한, 단순한 네트워크 서비스입니다. 누구든지 로그에 인증서를 등록할 수 있지만, 인증 기관이 최우선 등록자가 될 것입니다. 비슷하게, 누구든지 로그된 특정 인증서가 잘 로그되고 있는지, 그리고 인증서를 검증하기 위해서 암호 증명에 대한 로그를 조회할 수 있습니다. 로그 서버 개수는 많을 필요가 없고 (이를테면, 전세계에 1000개보다 적습니다), 각각은 인증 기관, 인터넷 제공 업체 또는 어떤 다른 조직에서든지 독립적으로 운영될 수 있습니다.

감시자 (Monitors)

감시자는 주기적으로 모든 로그 서버와 접촉하면서 수상한 인증서에 대한 주시를 공개적으로 실행하는 서버입니다. 예를 들어, 감시자는 인증 기관을 잃었거나 인증되지 않은 인증서가 도메인에게 발급되었는지, 비정상적인 인증서 확장이나 인증 기관이 갖고 있는 인증 권한 같은 이상한 권한을 갖고 있는지 알려줄 수 있습니다.

감시자는 대출이나 신용 카드에 여러분 이름으로 누군가 사용할 때 알려주는 것과 같은 신용 경고 알림과 매우 유사한 방식으로 동작합니다. 일부 감시자는 Google 또는 은행, 정부와 같은 회사와 조직에 의해 운영됩니다. 그 외에도 도메인 소유자나 인증 기관이 구매할 수 있는 구독 서비스를 운영할 것입니다. 기술에 정통한 개인도 스스로 감시자를 운영할 수 있습니다.

감사자 (Auditors)

감사자들은 크게 보아 두 가지 기능을 수행하는 가벼운 소프트웨어 구성 요소입니다. 첫째는 로그가 올바르게 쓰이고 있고 암호화가 유지되고 있는지 검증할 수 있습니다. 로그가 제대로 작성되지 않으면, 로그 스스로 이에 대해 서술해야 하고 그렇지 않으면 종료될 수 있습니다. 둘째로 특정 인증서가 로그에 나타나는지를 검증할 수 있습니다. 이는 감사 기능에서 특히 중요한데, 인증서 투명성 프레임워크는 모든 SSL 인증서가 로그에 등록되어 있을 것을 필요로 하기 때문입니다. 인증서가 로그에 등록되어 있지 않다면, 인증서가 수상하다는 의미이며, TLS 클라이언트는 수상한 인증서에 대한 연결을 거절할 것입니다.

감사자는 브라우저의 TLS 클라이언트, 단독 서비스, 아니면 감시자의 보조 기능으로서 필수 구성 요소가 될 수 있습니다. 누구든지 감사자를 만들 수 있는데, 이는 인증 기관이 모든 인증 기관에 대한 운영 투명도를 높일 수 있는 효과적인 방법이므로 인증 기관이 수많은 감사자를 운영할 것입니다.

아울러서, 이들 구성 요소가 실시간으로 새로운 또는 기존에 존재하는 SSL 인증서를 누구든지 관찰하고 검증할 수 있게 하는 공개 프레임워크를 구성합니다.2

오작동의 감소, 안전한 브라우징

이것이 구현되면, 인증서 투명성은 잘못 발급된 인증서, 악의적으로 취득한 인증서, 공격받은 인증 기관과 같은 인증서 기반 공격의 몇 종류에 대한 대비를 하는데 도움을 줍니다. 이 공격은 도메인 소유자의 금전적 손실 증가, 인증 기관의 신뢰 하락 그리고 인터넷 사용자를 웹 사이트 스푸핑, 서버 위장, 중간자 공격과 같은 광범위 공격으로 노출할 수 있습니다.

인증서 투명성 프레임워크는 공개 조사 제공 및 SSL 인증 시스템 개방을 통해 이들 인증서 기반 위협을 격리시키는 것을 목표로 합니다. 비록 공개 프레임워크가 공개적으로 감시자와 감사자에 의해 구통되지만, 인증성 투명성은 현행 SSL 인증 시스템에 빠져있는 몇몇 이점을 제공합니다.

잘못 발급된 인증서, 수상한 인증서, 공격 받은 인증 기관의 조기 탐지

대부분의 경우, 인증서 투명성 시스템은 수상한 인증서나 인증 기관을 수 일, 수 주, 수 개월을 수 시간으로 단축하여 탐지할 수 있습니다.

수상한 인증서나 인증 기관이 감지되었을 때 빠른 이탈

인증서 투명성이 위험한 인증서와 인증 기관을 다루는 기존의 해결 방식에 의존하긴 하지만(예를 들어 인증서 철회), 단축된 탐지 시간은 위험한 인증서나 인증 기관이 발견되었을 때 전체 해결 과정을 가속할 수 있습니다.

전체 TLS/SSL 시스템에 대한 더 나은 확인

인증서 투명성은 새로 발급되거나 존재하는 TLS/SSL 인증서에 대한 공개 감시 및 검증을 지원하는 공개 프레임워크로 설립되었습니다.  이에 (도메인 소유자, 인증 기관, 사용자 같은) 관심 있는 이들에게 TLS/SSL 시스템의 투명도와 상태를 관찰하고 검증할 수 있는 기회를 제공합니다.

집중 솔루션으로서, 인증서 투명성은 HTTPS 연결을 더욱 신뢰할 수 있고 정보 탈취 및 위장으로부터 안전하게 만듦으로써 인증 기관으로부터 개인 서버까지 확장된 신뢰 체인을 강화합니다. 그러나 그 이상으로, 일반적인 보안 관점에서, 인증서 투명성은 광범위한 인터넷 보안 공격을 방어하고, 모든 사용자가 안전하게 브라우징할 수 있도록 도와줍니다.

다음글: 2. 인증서 투명성 작동 방식