何故今テレコムで証明書が騒がれているのか？

3GPP、ETSI-NFV、O-RANと様々な団体で証明書に関する議論が起き始めている。何故今証明書が重要なのかを、テレコムの進化や運用や観点から考えてみたい。

識別子としての証明書

「時代を映すインフラ」(国立情報学研究所)や「知識の森 第5群4編ノード技術」(IEICE)の通り、元々テレコムにおいては、端末〜端末間をPoint to Pointの専用線で繋ぐ思想だった。その識別子がチャネル/VCI→IPと変わってきただけで、根本的なNWトポロジー(構成や機能分担)はあまり大きく変わっていない。

テレコムの運用においては、この交換機等のNW設備の“箱“を専用線で繋げる発想であったため、NW設計も保守運用の考え方も、この箱と専用線単位となっている。「テレコムアプリの実装の特徴と監視方法②〜EM編〜」にも記載している通り、EMは各設備のFCAPSを装置単位に管理している。通信方式がIPになったとしてもこの考え方は大きくは変わっておらず、IPアドレスで設備を識別・管理し、VLANで専用線を管理している。

5GC以降、「REST指向での標準仕様設計方法」の通りSBAやRESTと言ったよりダイナミックでフレキシブルなプロトコルを利用されるようになり、ここで装置の識別子が装置から証明書に変わってきた。

5Gにおいては、Serviceベースでの仕様となりNF(Network Function)の構成やNWの接続先をDynamicに変更しやすくなった。その結果、従来のようなIPアドレスによる装置単位の監視保守は維持できず、リソースを管理するResource Manager (5GCではNRF)が動的に増減・変更されるNFを管理するようになった。これにより、監視方法もトラヒック管理方法も変わってきている。また、IPアドレスで装置を管理することが困難になり新たな識別子の管理方法として証明書が利用されるようになった。

証明書の利用方法

3GPP TS 33.501やETSI GS NFV-SOL 013の通り、SBAにおいてはmutual TLS (mTLS)による認証＆セキュア通信と、OAuthによる認可が通信のベースになっている。この時、各NFを識別しているのは”証明書”となる。SEの道標というサイトにおいて、mTLSとOAuthによる認可認証の仕組みはmTLS相互認証の仕組み、証明書を利用した認証の仕組みはクライアント証明書の仕組みを分かりやすく説明している。

現在の5GCやNFVの仕様をまとめると、通信するためにはClientとServerを利用したmTLSによる認証と、client certificateを利用したTokeの発行を行なっている。従来のようなIPアドレスベースではNFの管理をしておらず、全て証明書(certificate)でNFを管理している。

5GCのSBAやNFVの仕様はClient Serverモデルとなっており、ServiceはAPIをProduceし、ClientはAPIをConsumeするモデルになっている。Clientは自身が持っているClient certificateを利用してResource  ManagerからTokenを入手し、そのTokenとClient CertificateでAPI  ProducerにRequestを投げることになる。5GCではResource ManagerはNRFであり、NFVではAuthorization Serverと呼ばれている(今後新規定義される可能性あり)。

問題は、通信先を識別するためにcertificateをVerifyするためには、そのcertificateを発行している認証局のroot certificate/intermediate certificateが必要となる。現在の標準仕様ではこのroot証明書などを配布する仕様や仕組みがないため、現在仕様の制定が始まっている。

セキュリティはもはや脅威からの保護ではなく、マルチテナント環境での装置の識別子として利用され始めている。このようなNW構成の変更や運用の変更に証明書が大きく関わっているため、証明書の重要度が上がってきた。今回は運用の観点で証明書の位置付けを説明したが、従来通りのような脅威からの保護に対する暗号通信や、コンテナを含むパッケージの識別子など、様々利用されている。その一方で、証明書を管理する仕組みはまだまだ成熟していない。まだ記憶に新しいが2018年の世界大規模通信障害も証明書の有効期限切れが原因と言われている。今後テレコムのNW機器がServiceベースとなると、証明書の管理は必須機能の一つとなるだろう。