In our last blog, we talked about the PQC signature algorithms standardized and currently being evaluated by NIST. Some of the key characteristics of these algorithms are: Before we go into specific numbers, we first need to define some terminology. Security levels All signature algorithms have several different variants based on what’s called “security levels.”…
前回のブログでは、NISTによって標準化された、また現在評価が進められているPQC署名アルゴリズムについて取り上げました。これらのアルゴリズムの主な特徴は以下の通りとなります。 具体的な数値について触れる前に、まずいくつかの用語を定義しておく必要があります。 セキュリティーレベル すべての署名アルゴリズムには、「セキュリティレベル」と呼ばれるカテゴリーの定義に基づいて、いくつかの異なるバリエーションが存在します。セキュリティレベルは5段階（カテゴリー1～5）あり、レベルが上がるにつれてセキュリティ強度が高くなります。これらのレベルは以下の通りです： 公開鍵と署名サイズ 公開鍵と署名の大きさは、各アルゴリズムの基となる数学的問題（格子、多変量など）およびセキュリティレベル（1～5）によって決まります。セキュリティレベルが上がるにつれて、各アルゴリズムタイプにおける公開鍵および署名のサイズも大きくなります。以下の表2には、公開鍵とそれによって生成される署名のサイズ、およびECDSAに対する相対的なサイズの比較が記されています（表の見出しでは、それぞれ「|PK|、Ratio vs. ECDSA (x)」および「|Sig|、Ratio vs. ECDSA (x)」と表記されています）。 表2からわかるように、すべてのアルゴリズムにおいて、公開鍵および署名のサイズは、従来のECDSA（1列目）と比較して大きくなっています。一部のアルゴリズムでは、その増加の程度が顕著であり、多変量ベースのアルゴリズム（OVなど）では公開鍵のサイズが1万倍以上、CROSSでは署名サイズが千倍以上にもなっています。一方、SPHINCSやFAESTでは公開鍵の増加幅ははるかに小さく、MAYOやOVでは署名サイズの増加幅がはるかに小さくなっています。一般的に言って、ハッシュベースのアルゴリズム（SPHINCS等）では公開鍵は比較的に小さいが署名サイズが大きくなり、多変量ベースのアルゴリズム（OV等）では公開鍵は大きい割には署名サイズが小さめ、という特徴があります。 同様に、署名の生成および検証の処理時間も、ECDSAと比較して増加する（処理が遅くなる）傾向があります。ここでは図には示していませんが、シミュレーションの結果からこのことが分かっています。署名生成にかかる時間はアルゴリズムによって異なりますが、一般的なノートパソコンでは、一つの署名生成の処理に数秒をはるかに超えるものもあります。対照的に、署名の検証時間はすべての署名アルゴリズムでほぼ一貫しており、数ミリ秒程度となっています。 今回のブログは比較的短くなりましたが、次回のブログでは、こうした公開鍵や署名のサイズ増加、およびパフォーマンスの低下が意味するところについて解説します。
PQCアルゴリズムの標準化 NISTは2016年にPQCアルゴリズムを規定するための標準化活動を開始し、その後一連の評価ラウンドを実施しました。3回の評価ラウンドを経た結果、2022年にIR 8413 (2022-07)が公表され、1つの鍵交換メカニズム（KEM）と3つのデジタル署名アルゴリズムを規定しました。前者は秘密鍵をカプセル化（暗号化）して機密性を確保しつつ伝送するためのもので、後者はRSAおよび楕円曲線デジタル署名アルゴリズム（ECDSA）に取って代わると期待されている署名アルゴリズムとなります。 標準化されたアルゴリズム (IR 8413) KEM Original name Official standard name Algorithm type CRYSTALS-Kyber ML-KEM (FIPS 203) Lattice-based Table 1: KEM algorithm デジタル署名アルゴリズム Original name Official standard name Algorithm type CRYSTALS-Dilithium ML-DSA (FIPS 204) Lattice-based Falcon FN-DSA (FIPS 206) Lattice-based SPHINCS+ SLH-DSA (FIPS 205) Hash-based Table 2: Signature algorithms 追加の署名アルゴリズム IR 8413の公表後（第3ラウンドの評価終了の時点で）、他に残った署名アルゴリズムの候補はない状態となりました。そこで署名アルゴリズムのポートフォリオを拡充するため、NISTは追加の署名アルゴリズムの公募を発表しました。 この公募の動機の一部は、格子ベースのアルゴリズム（ハッシュベースのSPHINCS+を除く）以外のアルゴリズムの多様化を図ることにありました。さらに、この公募では、「署名の短かい、かつ検証が高速な」アルゴリズムが具体的に言及されていました。本稿執筆時点において、IR…
NIST PQC standardization activities NIST started the standardization activities to specify PQC algorithms in 2016, followed by a series of evaluation rounds. In 2022, after 3 rounds of evaluation, NIST published IR 8413 (2022-07), which specified 1 key encapsulation mechanism (KEM) and 3 digital signature algorithms. The former is to confidentially transmit a secret key…
In the last blog, we talked about the general background and motivation of migrating to post-quantum cryptography. In particular, we discussed the underlying mathematical problems used in public key cryptography: (1) large number factorization problem, and (2) the discrete logarithm problem. In this blog, we go into a bit more detail about how those mathematical…
前回のブログでは、ポスト量子暗号への移行に関する一般的な背景と動機について解説しました。特に、公開鍵暗号で用いられる基礎となる数学的問題、すなわち (1) 大数の因数分解問題と (2) 離散対数問題について取り上げました。今回のブログでは、これらの数学的問題が、公開鍵暗号の構成要素としてどのように使われているについて、もう少し詳しく解説します。 大数の因数分解問題（RSA） RSA暗号 一つ目は、大数の因数分解の問題です。前回のブログでも触れたように、これは与えられた大きな数から 2 つの因数を見つける問題であり、数が大きくなるとこれらの因数を見つけるのが難しくなるという特徴があります。ここでは、RSA暗号の仕組みについて簡単に説明します。 準備手順： 暗号化・復号の手順： 離散対数問題（ディフィー・ヘルマン、エルガマル） ディフィー・ヘルマン鍵交換（DHKE）： 準備手順： 鍵交換の手順： ここで注目すべきことは、イブ（盗聴者）は共有秘密鍵KK がわからない、ということです。なぜなら、AAとBB の計算に使用される xxと yyの値をイブは知らないからであり、これらの値は明示的に送信されないためである（つまり、イブはxx とyy の値を計算しようと試みなければならないが、これらは大きな数値になるため困難である、という前提のため）。 エル・ガマル暗号： エル・ガマル暗号は、実際にはディフィー・ヘルマン鍵交換の変種と言えます。これは、アリスが C1(すなわちar(modp))C_1\, (すなわち a^r\,(mod\, p))を共有し、y=ax(modp)y=a^x\,(mod\,p)がすでにボブ向けの公開鍵として計算されているためである。したがって、ディフィー・ヘルマン鍵交換のメカニズムによって、ボブは秘密鍵 K=arx(modp)K=a^{rx}\,(mod\,p) を得ることになり、これによりメッセージが復号できることになります。 準備手順： 暗号化／復号手順： もう一つの離散対数問題（楕円曲線） 楕円曲線： 楕円曲線暗号はもう一つの離散対数問題によるものです。これは前述のもののような、指数を直接的に使った計算とはまた違ったものとなります。楕円曲線は、y2=x3+ax+by^2=x^3+ax+bの方程式で表され、a,ba,bの値によりその形が変わります。その例を示す(a,b)=(−1,1)(a,b)=(-1,1)の場合の図は、次のようになります： 曲線上の2つの点の「加算」演算は定義されていますが、従来の算術とは異なりかなり奇妙なものです。2つの点、点a(x1,y1)a\,(x_1,y_1)と点b(x2,y2)b\;(x_2,y_2) を定義し、加算の結果得られる座標を点 c(x3,y3),c\;(x_3,y_3),、すなわちc=a+bc=a+b と表すと、その定義は以下の通りです（以下の ppは大きな素数です）： 見た目には、上の2つの図のようになります。曲線上の2つの異なる点a+ba+b を足し合わせる場合、まずこの2点を通る直線を引き、その直線が曲線と交わるもう一方の点（黄色の点）を取り、それをxx 軸で反転させます。その結果得られる点（赤で示されている）が a+ba+b となります。自身に足す場合、つまり2a2a の場合、まず曲線上の点 aa を通るカーブ上の接線を引きます。その接線と曲線のもう一方の交点（黄色の点）を取り、それを xx 軸で反転させます。その結果得られる点（赤の点）が 2a2a となります。 楕円曲線における点での「乗算」演算は、実際にはそれ自身の加算、すなわちa,2a,3a,4a…Naa, 2a,…
これは、ポスト量子暗号（Post Quantum Cryptography (PQC）について、更に、従来の暗号アルゴリズムからPQCアルゴリズムへの移行に関するシリーズの第1回です。 暗号の安全性について まず、暗号アルゴリズムには大きく分けて2つの種類があります（暗号化、署名、鍵の共有等）。 これた2つのうち、共通鍵暗号の方がより分かりやすく、実際ローマ時代から何世紀にもわたって存在してきました。この方式では、メッセージを暗号化および復号化する鍵が同じものである、ということです。言ってみれば玄関のドアを施錠・解錠するための家の鍵のように、非常にわかりやすいと思います。通信システムでの前提では、メッセージの送信者と受信者の双方が、何らかの方法でこの鍵を共有しているということです。Advanced Encryption Standard（AES）は2001年に米国国立標準技術研究所（NIST）によって標準化され、現在最も広く使用されている共通鍵暗号アルゴリズムです。 一方、公開鍵暗号は（1976年にようやく登場したばかりの！）比較的新しい概念であり、ここではメッセージの暗号化と復号化には異なる鍵が使われます。家の鍵に例えるなら、ドアを施錠するための鍵と解錠するための鍵が異なるというわけです。これは、（1976年に有名なディフィー・ヘルマンの論文が発表されるまでは）そのようなことが可能だとは誰も考えていなかったという点で、非常に画期的な概念です。これには、公開鍵と秘密鍵という2つの鍵が関わっています。その名の通り、公開鍵は誰にも共有することができますが、一方、それに対応する秘密鍵は所有者のみが保持するものです。通信システムでは、送信者は公開鍵を使ってメッセージを暗号化し、受信者（公開鍵と秘密鍵のペアの所有者）は秘密鍵を使ってそれを復号します。 公開鍵暗号の安全性は、秘密鍵の機密性に依存しています。つまり、もし秘密鍵が解読されてしまえば、誰でもその鍵の正当な所有者を装うことが可能になってしまいます。RSA、ディフィー・ヘルマン鍵交換、エル・ガマル、楕円曲線暗号（ECC）は、公開鍵暗号の一種です。 公開鍵暗号の根本的な特徴は、いくつかの数学的問題の解くことの難しさに基づいている点です。具体的には、特定の数学的演算の一方向性（逆演算が困難であること）が、その重要な構成要素となっています。要するに、逆演算を行うのに極めて長い時間がかかる場合（例えば、最高性能のコンピュータでも必要な計算に数千年以上を要するといった場合）、そのアルゴリズムは現実では事実上安全であると見なされます。これは相対的な概念です。時間はかかるかもしれませんが理論上は依然として可能であり、その安全性は既存の（最高性能の）コンピュータの性能制限によって守られているとも言えます。言い換えれば、この前提が成り立たなくなれば、このセキュリティの原則は崩壊してしまうことになります。 そのような数学的問題には、(1) 巨大な数の因数分解（RSA、ディフィー・ヘルマン）、および (2) 離散対数問題（ディフィー・ヘルマン、エル・ガマル、ECC）があります。これらのアルゴリズムの詳細については、別のブログ記事で取り上げる予定です。ここでは、ごく大まかな概要にとどめておきます。 １．巨大な数の因数分解 2つの整数 pp と qq があるとき、これらを掛けることはいたって簡単です。 掛け算のやり方は誰もが知っていることです。たとえ両方の数が大きくても、計算することは可能です。ただし、手計算だとすぐに面倒で時間がかかのでやめてしまいますが（コンピュータにとっては依然として簡単な処理です）。一方、整数の因数分解は、数が大きくなるにつれて非常に時間がかかり、「難しい」ものになります。例えば、143の因数分解なら、紙とペンを使わずにも頭の中で計算できるレベルです（11 × 13）。しかし、477,568,881,191の因数分解ははるかに難しく、間違いなく時間がかかります（477,577 × 999,983）。もし紙とペンしか使えなければ、そもそもやろうとも思わないでしょうし、暗算で解くことなど論外です。600桁を超える10進数（つまり2048ビットの2進数で表される数）の因数分解などまったく想像もつきませんね。 同様の状況がコンピュータにも当てはまります。巨大な数を因数分解するための効果的で高速なアルゴリズムが存在しないため、桁数が増えるにつれて、因数分解には非常に長い時間がかかるということになります。 2．離散対数問題 もう一つの一方向性の問題として、いわゆる離散対数問題があります。これは、剰余演算を用いた次の式で表されます。 ここで、nn は大きな素数であり、aa と xx は、xx の値が大きくなるように、aa が nn より小さい数（つまり、a<na<n）となるように定義されます。この式において、a,x,na,\,x,\,n が分かっていれば、cc を計算するのは容易です。しかし、c,a,nc,\,a,\,n が与えられたとしても、そこからxx（大きな数）を求めるのは困難です。この難しさの一因は、モジュラー算術（すなわち (modn)(mod\, n) の部分）にあります。これは、axa^x の値が nn を何周するかを「隠してしまう」ためです。xxが大きな数である場合、そのxx のすべての値を総当たりで試すことは、非常に時間のかかる作業となります。 量子コンピュータの登場 さて問題は、十分に高性能な量子コンピュータが現実のものとなった場合、これら2つの「難問」の想定されていた安全性が脅かされるという点です。量子コンピュータはすでに存在していますが、膨大な桁数が関わるこれらの問題を解くには、さらにはるかに高性能な量子コンピュータが必要になると予想されています。現在の量子コンピュータの中には、物理的な量子ビット（qbit）の数が最大1万個程度に達するものもあると言われています。しかし、物理量子ビットは非常に脆弱でエラーが発生しやすく、実用上は信頼性が低いものです。そのため、実際に利用可能にするには、エラー訂正機能を備えた、より安定して信頼性の高い論理量子ビットに変換する必要があります。現在の論理量子ビットの数は、100個未満程度とされています。 1994年に発表されたショアのアルゴリズムは、量子コンピュータが多項式時間で大きな数を因数分解できることを示しました。これは事実上、「困難な」問題に依存するアルゴリズムが、量子コンピュータの前ではもはや安全ではないことを意味します。これは大きなパラダイムシフトであり、「数千年以上かかる極めて時間のかかる計算」とされてきた前提が崩れることになります。したがって、十分に強力な量子コンピュータでショアのアルゴリズムを実行すれば、従来想定されていたアルゴリズムの安全性はもはや成り立たなくなることを意味します。 「今保存し、後で復号する」（”Store now, decrypt…
前回のブログでは、プライバシー保護のための標準化のソリューションと、それに伴う問題点について取り上げました。その記事の終わり辺りで、車両と交通弱者（VRU）との間のプライバシー保護に関する違いについてはまだ未解決の課題が残されていると簡単に触れました。 実際、VRUの実現に関する課題はプライバシーの側面だけにとどまりません。このブログでは、VRUに関する複数の問題点について述べます。 まず、語彙の定義です。VRU（「脆弱な道路利用者」＝いわゆる「交通弱者」）という語彙は、事故が発生した際に車両よりも負傷しやすい傾向にあることから付けられました。これに関する標準規格によると、これには歩行者、自転車（通常の自転車および電動自転車）、電動キックボード、原付バイク、オートバイ、道路作業員、さらには動物など、車両以外の道路利用者が含まれます。 VRUメッセージの目的 VRUに関するメッセージはVRU Awareness Messages （VAM）と呼ばれます。VAMメッセージの目的は、周辺の車両に対し「交通弱者」（VRU）の存在やその動きを通知・警告することです。車両の視点からVRUを正確かつ迅速に検知することは、車両だけでなくVRUにとっても、より安全な道路環境の実現につながります。これにより、事故からVRUを守り、その安全性を高めることにつながります。VRUのユースケースはETSI ITS仕様書TR 103 300-1に記載されています。 VRUのプライバシー保護 VRU（交通弱者の安全）と車両との大きな違いはユーザーとデバイスの関係性の違いにあります。車両の場合、車両とその運転手・所有者の間には明確な関係性は比較的薄いものです。個人所有の乗用車であれば、その関係性は確かに明確です。したがって、そうした運転手や所有者を保護することには明確な意味があります。しかし、バスやタクシーなどの他の種類の車両については、固定された関係性はありません。バスには複数の乗客が乗るものであり、乗降によって乗客は時間とともに変わり、これはタクシーについても同様です。バスやタクシーの運転手も、シフトの交代に伴い定期的に入れ替わります。では、こうした種類の車両において、私たちは誰のプライバシーを保護しているのでしょうか？ 自動車とは対照的に、VRU（「交通弱者」）については、一部のVRUの種類を除いて、スマホがそのデバイスとして使用されることが暗黙の前提となっています。例外としては、専用のVRUデバイスが組み込まれている自転車や電動キックボードなどが挙げられます。しかし、歩行者について言えば、スマホが使われるであろうことはとなるのは自然の成り行きでしょう。今日では誰もがスマホを使って、電話をかけたり、メールをチェックしたり、友人とチャットしたり、インターネットを閲覧したり、ゲームをしたり、音楽を聴いたり、支払いをしたりなど、あらゆることにスマホを利用しているという現実があります。そこにV2Xメッセージを送受信する「アプリ」がもう一つ加わるのは、ごく自然なことだと思います。ETSIの用語では、これをVRU認識メッセージ（VAM）と呼びます 、SAEではパーソナルセーフティーメッセージ(PSM)と呼ばれます。 この仮定が正しければ、あなたのスマホを使うのはあなただけですから、ユーザーとデバイスは完全に1対1の関係となります。家族と車を共有することはあっても、自分のスマホを人と共有することはありません。となると、それらのVRU（歩行者・自転車利用者）に対するプライバシー保護は、自動車よりもはるかに厳格で厳重なものにならざるを得ないという結論に達します。本質的には、位置情報の追跡などにおいて、スマホ利用と同等のプライバシー保護レベルとなることになります。 VRUの動きの特徴、その１ VRUには、上記に述べたプライバシー上の問題があるだけでなく、車両とは大きく異なるもう一つの点がその物理的特性にあります。車両は基本的にその大部分が鉄でできている大きな物体であり、一般的な乗用車でも重量は1トンを軽く超えます。大型トラックのようなより大きい車両の場合、その重量は数トンを超えます。一度動き出してしまうと、停止や方向転換などは容易ではありません。車両の運動量が大きいため、機敏な動きは難しくなります。 これとは対照的に、人間（歩行者）の慣性ははるかに低いという特徴があります。突然止まったり、素早く方向を変えたり、振り返って瞬時に反対方向へ歩き始めたりすることは容易です。車両に比べて人間の慣性は小さいため、人の動きははるかに予測しにくくなります。たとえVAMメッセージが歩行者の動きを周囲の車両に伝えるメッセージを送信できたとしても、その状態がたとえ短時間であっても維持されるという保証はありません。先ほど、動物もVRUの一員であると述べました。猫や犬を例に挙げてみましょう。 🙂 彼らの敏捷性は人間よりもさらに高く、その行動ははるかに予測が困難ものです。 こうした状況を考慮した上で、VAMメッセージがVRUの動きを正確かつ確実に反映させるにはどうすればよいのでしょうか。これは大きな課題です。さもなくばVAMメッセージは単なる「張子の虎」に過ぎない、という結果になってしまいます。更にVAMメッセージがVRUの実際の動きを正確に反映していないような場合には、誤った情報が車両を誤った認識をさせてしまうため、かえって害を及ぼす可能性さえあります。 VRUの動きの特徴、その2 VRUのもう一つの特徴としては、その状態が変化しうるということです。具体的には、次のようなことです。歩行者が道路脇のバス停に立っているとします。数分後、バスがバス停に到着し、その歩行者はバスに乗り込みます。ここでその人はもはや「歩行者」ではなく、バスの「乗客」となります。また、バスが目的地のバス停に到着すると、その「乗客」はバスを降りて歩き始めます。これで、この「乗客」は再び「歩行者」に戻る、ということになります。周囲の車両から見て、その人がバスの中にいるか外にいるかによって、歩行者の安全面において大きな違いが生じることは言うまでもありません。 ここで問題となるのは、こうした「状態の変化」がVAMメッセージにどのように正確に反映されるかということです。スマホに内蔵されたモーションセンサーが利用されることは当然予想されます。しかし、赤信号で停車中のバスに乗っている「乗客」と、道路脇に立っている「歩行者」は、どちらも動いていませんが、その「状態」は異なります。前者の場合、その人は依然として「乗客」であり、後者の場合は「歩行者」です。止まっている「乗客」と止まっている「歩行者」、これらを区別する必要があります。自転車に乗っている人（「サイクリスト」）と路肩で自転車を押している人（「歩行者」）で、その状態を切り替える場合にも、同様のことが当てはまります。これは現実的に機能するのでしょうか？規格ではユースケースやメッセージの定義が定められていますが、こうした側面については十分に検討されていないような印象を受けます。 オートバイは車両はVRUか？ このブログの冒頭で、オートバイはVRUの一種であると述べました。この定義によれば、オートバイは「車両」であると同時に「VRU」でもあります。これは、ある条件下では「車両」であり、別の条件下では「VRU」であることを意味するのでしょうか？もしそうだとすれば、どのような状況下でどのように切り替わるのでしょうか？オートバイは交通の流れの中で他の車両に混じって移動するため、VRUというよりは「車両」に近いように思えます（ただし事故に遭った際には、ライダーはより怪我をしやすいので「交通弱者」の範疇に入るのでは、と推察します）。 しかし、ここでさらに問題なのは、オートバイが転倒し、道路上でライダーとバイクが左右に離れてしまった場合、VAMの観点からはこれらが2つの独立した「存在」となり、それぞれ別々のVAMメッセージを送信し始めなければならないという点です。つまり、ライダー（人間）とバイク（物体）という2つの別の「物体」から発せられるメッセージになります。この動作の理由としては（私の理解では）、道路上に2つの「物体」が離れて（片側にライダー、もう片側にバイク）存在している状況を、付近の車両に認識させる必要があることだからあろうと思います。例えば、後続車両が衝突を避けられない状況において、どちらに衝突するかという迅速な判断を下さなければいけない、という必要性があり、これらの「2つ」のメッセージがその判断に重要なものとなります。怪我を防ぎ、人命を救うという観点からすれば、どちらを選ぶべきかの答えは自明です。 この例では2つのデバイスが関与していることを意味します。1つはライダーが装着するもので、もう1つはバイクに固定されたものです。そして、ライダーがオートバイに乗っている間、および道路上で転倒してオートバイから投げ出された際に、これらのデバイス間の「一体化」と「分離」が適切に行われる必要があることを意味します。もしこれら2つのデバイスがBluetoothのような無線技術によって接続されていると仮定すると、この「一体化」と「分離」が意図した通りに機能するかどうかは疑わしいと考えます。理由としては、Bluetoothの通信距離はバイクが転倒しライダーが車体から投げ出される際のこの2者間の距離よりもはるかに長いためです。 これを実現するには、もっと物理的・機械的な方法が必要になると思います。スポーツジムのトレッドミルによく見られる、磁石付きの赤い紐が思い浮かびます。シャツにその紐を留めておくと、バランスを崩してトレッドミルから落ちた瞬間に磁石が外れ、マシンが即座に停止する、という仕組みです。 VRUの実装は如何に？ これはこのポストでおそらく最も根本的な問いになるかもしれません。この点について議論するには、まずV2X通信の基盤となる無線技術について確認する必要があります。V2Xの規格には、Dedicated Short Range Communications（DSRC）とセルラーV2X（C-V2X）の2つがあります。前者はIEEEによって定義されるWi-Fi（IEEE 802.11p）を利用し、C-V2Xは4Gや5Gなどの移動体通信技術を規定する標準化団体（SDO）である第3世代パートナーシッププロジェクト（3GPP）によって標準化されています。 後者（C-V2X）の場合、デバイス間の直接通信インターフェースは、モバイルシステムアーキテクチャの観点からは「PC5」（システム参照ポイントの名称）、また無線アクセス技術の観点からは「サイドリンク」と呼ばれます。対応するモバイルシステムの世代に応じて、LTE（4G）ベース（LTE C-V2X）と5Gベース（5G C-V2X）の2つのバリエーションがあります。 前述の通り、ここにはVRU（特に歩行者）がこの目的でスマートフォンを利用するという暗黙の前提があります。現在、消費者の間でのスマホの普及を考えれば、VRU専用の端末のような特定用途向けの端末を一般消費者が購入・使用する可能性はまずないであろうと考えます。その昔はウォークマンなどの音楽再生専用のデバイスもありましたが、今どきはそのような特定用途のデバイスを買う人は（一部のマニアを除いて）まずいないでしょう。 より根本的な問題・疑問へ ここでの疑問は以下のようなものとなります。一般消費者が使うスマホはC-V2XのPC5/サイドリンク・インターフェースに対応するのでしょうか？ 私の推測では、答えは「ノー」だと思います。PC5/サイドリンクは元々パブリックセーフティー向けに標準化されたものである、という背景があり、その後、V2X向けにその機能が再利用されることになったという背景があります。（QualcommのSnapdragonのような）ベースバンドプロセッサは、車載OBUなどの特定用途向け製品においてのみPC5/サイドリンクに対応しているのではと推察し、一般的なスマホ製品がPC5/サイドリンクに対応したベースバンドプロセッサを採用するかどうかは、極めて疑わしいと考えます。 私の推測が間違っていなければ、通常のスマホがPC5/サイドリンクに対応するようにはならないでしょう。であれば、C-V2XベースのVRUは単なる概念のみの「張子の虎」状態であり、それ以上でもそれ以下でもありません。となれば、どうしてもスマホでVRU機能を実装するのであれば、DSRCが唯一の実用的な選択肢となると思われます。 これは、C-V2Xが主流となっている米国や中国などの状況とは相いれない状況です。そうなると、異なる目的のために2つのV2Xの通信技術が共存しなければならない状況が生じることになります。これはどのように機能するのでしょうか？周波数帯の割り当てや、干渉を起こさずに2つのアクセス技術が共存することは可能なのでしょうか？これはまさに、各国の当局が様々な理由から技術の統一を図ることで回避しようとしてきた問題そのものです。これまで、DSRCとC-V2Xの共存について論じた学術論文は存在しました。しかし実際には、技術的およびその他の様々な理由から、このような状況は実現不可能だと考える次第です。 終わりに 本ブログでは、VRUには様々な問題が存在することを述べました。これらの技術的な問題の一部は、技術的なこと以外の問題を引き起こす可能性があり、その結果、解決策がさらに不透明になる恐れがあると考えます。全体をまとめた私の見解としては、ひいき目に見てもVRUの導入と普及が成功する可能性は、かなり限定的なユースケースやサービスタイプに留まるものだと考えます。 本ブログでは、V2Xの「セキュリティ」面というよりは、むしろ「安全性」の側面に関するものになりました。しかし、V2Xサービス全体の整合性という観点からは、これは非常に重要な事柄であると思います。 VRUに関する重要な点はほぼほぼ網羅できたと思いますので、これに関する議論はここで一旦終わりにしたいと思います。次回の記事でどのトピックを取り上げるかはまだ決めていませんが、また何か面白いトピックについて書こうと思います。
In my last post, we talked about the standardized solution for privacy protection and the problems associated with it. Toward the end of it, I briefly mentioned that there is an open question regarding the privacy protection differences between vehicles and Vulnerable Road Users (VRUs). In fact, the questions regarding implementing VRUs is more than…
In my last post, we talked about misbehavior detection and difficulties associated with it. That’s not the only problematic area in the security and privacy of V2X communication. In this post, I’d like to talk about another such topic – privacy protection. The standardized solution for privacy protection of V2X communication is rather simple and…