idベース暗号の概観と今後の展望（次世代セキュア情報基盤ワークショップ...

IDベース暗号の概観と今後の展望2013年8月29日

東邦大学金岡晃

Agenda

2013/8/29 次世代セキュア情報基盤ワークショップ 1

自己紹介：なぜこういったアプローチを取っているか

IDベース暗号とは

IDベース暗号の仲間たち

従来の公開鍵暗号との違い

IDベース暗号に渦巻く誤解：PKI不要論

IDベース暗号の使われるべき場所

これまでのアプローチ紹介

自己紹介


金岡晃（かなおかあきら）

東邦大学理学部情報科学科講師

情報通信研究機構（NICT）ネットワークセキュリティ研究所招へい専門員

• 専門分野• ネットワークセキュリティ

• ネットワークシステムの最適設計• DDoS対策

• 暗号実装・応用• IDベース暗号のシステム実装と運用

• セキュリティの見せる化

• その他• 電子メール：akira.kanaoka AT is.sci.toho-u.ac.jp• Twitter: akirakanaoka• facebook: 金岡晃（Akira Kanaoka）

32013/8/29 次世代セキュア情報基盤ワークショップ

経歴と研究・業務内容


ポジション研究・業務内容

修士（東邦大）通信理論（有色雑音下での最適CDMA）

博士（東邦大→筑波大）ネットワークセキュリティ（侵入検知システム＋機械学習）

研究員（セコム）ネットワークセキュリティ＋電子認証

ポスドク研究員（筑波大）

NEDO半導体アプリケーションチッププロジェクト「Pairing Liteの研究開発」（ペアリングを用いた暗号の応用検討）

教員（筑波大）招へい専門員（NICT）

ネットワークセキュリティ＋暗号の応用＜現在の研究＞

教員（東邦大）

IDベース暗号

• IDに基づく暗号• 「Identity、Identificationの略語」「個人を特定することが可能な情報」

電子メールアドレス、携帯電話の番号、基礎年金番号等

（CRYPTRECレポート“IDベース暗号に関する調査報告書”より）

• 広義のIDベース暗号と狭義のIDベース暗号• 広義のIDベース暗号

• 電子認証、電子署名、暗号化などの暗号プロトコルをIDを用いて実現する方式

• Identity-based Cryptography → IBC

• 狭義のIDベース暗号• IDを用いた暗号化方式

• Identity-based Encryption → IBE


ID管理やID連携の分野の人たちから見ると、Identityと言わずIdentifier（識別子）と言うべき


Adi Shamir, “Identity-Based Cryptosystems and Signature Schemes”CRYPTO 84

1984 → 2000


境隆一, 大岸聖史, 笠原正雄,”Cryptosystems Based on Pairing",暗号と情報セキュリティシンポジウム (SCIS2000), 2000

D. Boneh and M. Franklin, “Identity-based encryption from the Weil pairing," CRYPTO 2001, 2001

IDベース暗号の特徴


公開鍵がID

メールアドレスそのものが公開鍵として利用可能

でも実際は…

任意のデータを公開鍵に設定可能

「IDベース暗号の仲間たち」の生まれる素地

IDベース暗号の仕組み（概要）


プライベート鍵発行依頼

データ復号

KGC（Key Generation Center）

暗号文作成者

復号者

セットアップ（マスタシークレット、パラメータ）

ユーザプライベート鍵生成

ユーザ認証

パラメータ配布

パラメータ取得

データ暗号化

IDベース暗号（IBE）を現実化したペアリング


ペアリング

2入力1出力関数 𝑒(𝑃, 𝑄)

2つの特性：双線型性、非退化性

𝑒 𝑃1, +𝑃2 𝑄 = 𝑒 𝑃1, 𝑄 𝑒 𝑃2, 𝑄

𝑒 𝑃, 𝑄1 + 𝑄2 = 𝑒 𝑃, 𝑄1 𝑒 𝑃, 𝑄2

双線型性

楕円曲線上の点を入力としてペアリングを構成

暗号に使える𝑒 𝑎𝑃, 𝑄 = 𝑒 𝑃, 𝑎𝑄 = 𝑒 𝑃, 𝑄 𝑎

楕円曲線上の点を使うと𝑎𝑃 と𝑃がわかっても𝑎を求めるのは困難

ペアリングを利用した暗号

• IDベース暗号

•属性ベース暗号

•Timed Release暗号

•キーワード検索暗号

•Short Signature

•放送型暗号

•グループ署名

…その他大勢


きっかけはIDベース暗号へのペアリング利用

IDベース暗号の仕組み（BF）


Setup （サービスのセットアップ）

Extract（ユーザのプライベート鍵（復号鍵）の取得）

有限体𝐺1、𝐺2、ペアリング𝑒の選択、楕円曲線上の点𝑃、乱数𝑠の選択

ハッシュ関数𝐻1、𝐻2、楕円曲線上の点𝑃𝑝𝑢𝑏 = 𝑠𝑃の計算

乱数𝑠がマスタシークレット。あとは公開パラメータ

ユーザの𝐼𝐷からプライベート鍵 𝑑𝐼𝐷 = 𝐻1 𝐼𝐷 を計算

IDベース暗号の仕組み（BF）＜続き＞


Encrypt（暗号化）

Decrypt（復号）

乱数𝑟を選択。 𝑔𝐼𝐷 = 𝑒 𝐻1 𝐼𝐷 , 𝑃𝑝𝑢𝑏 と𝑟𝑃を計算。暗号文𝐶 =< 𝑟𝑃,𝑀 ⨁𝐻2 𝑔𝐼𝐷

𝑟 >を作成

受け取った暗号文𝐶 =< U, V >に対し、プライベート鍵𝑑𝐼𝐷を使って下記の計算をしてメッセージを得る

𝑀 = 𝑉⊕𝐻2 𝑒 𝑑𝐼𝐷 , 𝑈

𝑒 𝑎𝑃, 𝑄 = 𝑒 𝑃, 𝑎𝑄 = 𝑒 𝑃, 𝑄 𝑎の特徴を利用

IBE標準化動向：IETF• RFC 5091：Identity-Based Cryptography Standard (IBCS) #1: Supersingular

Curve Implementations of the BF and BB1 Cryptosystems• 2007年12月発行

• RFC 5408：Identity-Based Encryption Architecture and Supporting Data Structures

• 2009年1月発行

• RFC 5409：Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS)

• 2009年1月発行

• RFC 6267：MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)

• 2011年6月発行

• RFC 6507：Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI)

• 2012年2月発行

• RFC 6508：Sakai-Kasahara Key Encryption (SAKKE)• 2012年2月発行

• RFC 6509： MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY)

• 2012年2月発行

• RFC 6539：IBAKE: Identity-Based Authenticated Key Exchange• 2012年3月発行


IDベース暗号を使った応用研究＜抜粋＞

• D.K. Smetters, et. al., “Domain-Based Administration of Identity-Based Cryptosystems for Secure Email and IPSEC”, USENIX Security 2003

• IBCの公開パラメータ配布にDNSを利用する

• S. Meiklejohn, et. al., “The Phantom Tollbooth: Privacy-Preserving Electronic Toll Collection in the Presense of Driver Collusion”, USENIX Security 2012

• 車の料金支払いシステムの一部にIDベース暗号を応用。車一台一台がKGCとなり、通過と支払の証拠情報を暗号化して送信。監査などの必要が生じたときに車が復号鍵を発行。

• S. Ruoti, et. al., “Confused Johnny: When Automatic Encryption Leads to Confusion and Mistakes”, SOUPS 2013

• メール暗号化にIDベース暗号を利用。暗号の自動化が余計にユーザに混乱をもたらすというユーザビリティの研究。


ETC: Milo system


ドライバーの位置情報を秘匿した状態でドライバーが正しくToll Service Provider (TSP) に対し支払を行ったかどうかをToll Charger(TC)が検証するシステム

+

OBU: On Boot Unit private key

Request

Audit

Usage history

Usage history

4.

仲間たち


属性ベース暗号（Attribute based Encryption)

時限式暗号（Timed Release Encryption)

キーワード検索暗号（Keyword Searchable Encryption)

ユーザが持つ属性のリストを基に、復号可能な属性を指定して暗号化。受信者が復号可能な属性を保持していれば復号が可能な方式。IBEの「任意データ」の部分に属性リストが入るイメージ。

復号が可能となる時間（幅）を指定し暗号化する方式。受信者は、その時間になったら復号鍵を得ることができる。

暗号化された文書がキーワードを含むかを調べるために利用。文書暗号化は別の暗号方式で行うが、キーワードを含むかの検索にIBEの機構を利用する。

属性ベース暗号の系譜


Fuzzy IBE

Ciphertext-policy ABE (CP-ABE)

Key-policy ABE (KP-ABE)

関数型暗号

A. Sahai, B. Waters, “Fuzzy Identity-Based Encryption”, EUROCRYPT2005

V. Goyal, et. al., “Attribute-Based Encryption for Fine-Grained Access Control of Encrypted

Data”, ACM CCS 2006

L. Cheung, C. Newport, “Provably Secure Ciphertext Policy ABE”, ACM CCS 2007

T. Okamoto, K. Takashima, “Fully Secure Functional Encryption with General Relations from

the Decisional Linear Assumption”, CRYPTO 2010


鍵生成のタイミング

IBEでは、プライベート鍵（復号鍵）は暗号文生成時（暗号化時）には必要ない→ プライベート鍵の事後発行が可能。

鍵とIDの紐づけが不要

RSAやECCでは公開鍵がランダムに見えるデータなので公開鍵のみでは持ち主がわからないため紐づけが必要→ 後述する「PKI不要論の誤解」につながる


ユーザはプライベート鍵（復号鍵）を生成できない

IBEでは、プライベート鍵の発行はKGC（鍵生成センター）が行わなければならない。

鍵が失効されるときにIDも失効されないといけない

プライベート鍵の漏えいなどで鍵が危殆化した場合、公開鍵であるIDは利用してはいけなくなる。

「鍵とIDの紐づけ不要」≠「PKI（証明書）不要」


IDベース暗号は鍵とIDの紐づけが不要！ Yes!

IDベース暗号はPKI（証明書）が不要！ No!

PKI（とその証明書）が提供する機能は幅広い

鍵の用途所有者と鍵デー

タの紐づけ発行者情報

被発行者情報鍵の有効期限大規模化、オープン化されるとIBEにも必要になる情報→信頼に関わる情報

そもそも公開鍵基盤（PKI）ですし


プライベート鍵発行依頼

データ復号


暗号文作成者

復号者


ユーザプライベート鍵生成

ユーザ認証


パラメータ取得

データ暗号化暗号文作成者は、復号者は、

どうやってKGCを信頼する？

復号者が信頼しているKGCと暗号文作成者が信頼しているKGCが別だったら？

PKIの知見を活かす必要がでてくる（もしPKIと同様の使い方を望むなら）

IDベース暗号の方向性検討

• IDベース暗号が大規模化するに従い、必要となる機能・構造はPKIと同じになっていく


発想の転換が必要とされる

IDベース暗号の特徴を踏まえたアプローチ

発行者情報被発行者情報鍵の有効期限

KGCの信頼複数KGC下での

信頼確立

IDベース暗号の非基盤化


IDベース暗号は、IDとなる情報がすでに別の基盤として存在する状態で構築されることが考えられる

ID情報の基盤（アイデンティティ、属性、時刻情報など）

暗号的サービス

IDベース暗号

本来のサービス



本来のサービスIDベース暗号：

他の基盤上の1つのサービス

ID情報の基盤（アイデンティティ、属性、時刻

情報など）PKI

PKI：他の基盤と連携はするが独立性が高い

ID管理インフラ上の1つの暗号化サービス

• ID管理が用意な単一ドメイン• 組織内ユース

• 職員IDやメールアドレスを利用

• 特殊な用途• 機器IDなどを用いた暗号

• 今のPKIが使われているようなエリアではない• トラストリストによるオープンネットワークでの利用

• ブラウザとSSL

• 巨大なPKI構造としての利用


ID情報の基盤（アイデンティティ、属性、時刻情報など）

暗号的サービス

IDベース暗号




本来のサービスIDベース暗号：

他の基盤上の1つのサービス

ここがIBEの活きるエリアなのでは

例えば…：送信者が行なう暗号化と利用されるID• IDベース暗号の「ID」は本質的には「任意データ」

• 属性ベース暗号、時刻指定暗号などの応用が広まる

• 送信者IDを暗号化の鍵には使わない• 送信者IDの一部として、KGCパラメータが含まれる• KGCパラメータもID管理基盤上で管理される

• ユーザ（送信者）の属性データとして

• 送信者は他の情報を用いて暗号化する• ユースケース依存• 状況情報：時刻、場所、

測定値（温度、湿度、電力、etc.）

• 復号者は必要な情報に関するプライベート鍵の発行を求める

• 不必要なプライベート鍵発行をしない• 不必要な情報の復号を防ぐ


これまでのアプローチ：概要


運用の視点から

実装・システム化の視点から

KGCのロール分割、複数ドメインの検討

鍵管理とID管理の初期検討

汎用的に利用可能なKGC開発

SSLへのIBE適用→Apache+OpenSSL実装

低リソース機器でのIBE

外部ID基盤（Facebook）を利用したABE

C言語ライブラリTEPLAの開発



運用視点

実装・システム視点








大規模あるいはオープンな利用を想定

鍵発行センタの機能分割


KGC RA

+

鍵生成機能認証機能

IDの認証公開パラメータの配布

プライベート鍵生成

セットアップ(サーバシークレット, 公開パラメータ)

汎用的なIBE関連暗号システムの実現のため、KGCを各機能ごとに２つのエンティティ(KGC, RA)に分割する。

ロール間のやり取り


Original IBE

Receiver Sender

Proposal

Receiver Sender

KGC(Key Generation Center)

DomainInterface

RA(RegistrationAuthority)

KGC(Key Generation

Center)

提案フレームワークにおける３つのエンティティの定義


DomainIF

KGC

RA

KGCはプライベート鍵発行リクエストに対し鍵を発行するためのエンティティである。また、１つのKGCに対し１つのサーバーシークレットを持つものとする。

RAはFIが正しく管理されているかどうかを確認しプライベート鍵を発行してよいかどうかを認証するエンティティである。

DomainIFは各ドメインとの通信におけるゲートウェイとしての役割を持つ。ドメインは少なくとも１つはDomainIFを保持しなければならない。

エンティティが複数存在するケース


DomainIF

KGC B

RA

KGC A

KGC C

エンティティが複数存在するケースの分類


Entity Usecase ID

DomainIF KGC RA

1 single single single

2 single single multi

3 single multi single

4 single multi multi

5 multi single single

6 multi single multi

7 multi multi single

8 multi multi multi

管理ドメインと、複数ドメインの検討


ドメイン

同一の管理ポリシーにより構成される複数のエンティティ群エンティティは少なくとも１つのドメインに属さなければならない

複数ドメイン（マルチドメイン）ではどういうことが起こるかを検討しなければいけない

2013/8/29

次世代セキュア情報基盤ワークショップ

41

ID Domain Usecase

1-1 D1={DomainIF, KGC, RA}

2-1 D1={DomainIF, KGC, RA1, RA2}

3-1 D1={DomainIF, KGC1, KGC2, RA}

4-1 D1={DomainIF, KGC1, KGC2, RA1, RA2}

5-1 D1={DomainIF1, DomainIF2, KGC, RA}

5-2 D1={DomainIF1, KGC}, D2={DomainFI2, RA}

6-1 D1={DomainIF1, DomainIF2, KGC1, KGC2, RA}

6-2 D1={DomainIF1, KGC, RA}D2={DomainIF2, RA2}

6-3 D1={DomainIF1, KGC}D2={DomainIF2, RA1, RA2}

6-4 D1={DomainIF1, KGC}, D2={DomainIF2, RA1}, D3={DomainIF3, RA2}

7-1 D1={DomainIF1, DomainIF2, KGC1, KGc2, RA}

7-2 D1={DomainIF1, KGC1, KGC2},D2={DomainIF2, RA}

7-3 D1={DomainIF1, KGC1, RA}, D2={DomainIF2, KGC2}

7-4 D1={DomainIF1, KGC1},D2={DomainIF2, KGC2}, D3={DomainIF3, RA}

8-1 D1={DomainIF1, DomainIF2, KGC1, KGC2, RA1, RA2}

8-2 D1={DomainIF1, KGC1, KGC2, RA1}, D2={DomainIF2, RA2}

8-3 D1={DomainIF1, KGC1, KGC2}, D2={DomainIF2, RA1, RA2}

8-4 D1={DomainIF1, KGC1, KGC2}, D2={DomainIF2, RA1}, D3={DomainIF3, RA2}

8-5 D1={DomainIF1, KGC1, RA1, RA2}, D2={DomainIF2, KGC2}

8-6 D1={DomainIF1, KGC1, RA1}, D2={DomainIF2, KGC2, RA2}

8-7 D1={DomainIF1, KGC1, RA1},D2={DomainIF2, KGC2}, D3={DomainIF3, RA2}

8-8 D1={DomainIF1, KGC1}, D2={DomainIF2, KGC2}, D3={DomainIF3, RA1, RA2}

8-9 D1={DomainIF1, KGC1}, D2={DomainIF2, KGC2}, D3={DomainIF3, RA1}, D4={DomainIF4, RA2}

新たなプロトコルの必要性


Original FE

Receiver Sender

Proposal

Receiver Sender


DomainInterface

RA(RegistrationAuthority)

KGC(Key Generation

Center)

PKG

IETF RFC

Required



運用視点









「ID＝公開鍵」という特徴がもたらす鍵管理とID管理の依存性の検討

2013/8/29

鍵管理の全体像（SP800ｰ57、800-130をベースに金岡が作成）

次世代セキュア情報基盤ワークショップ 44

対称鍵、公開鍵、プライベート鍵

一時鍵/静的鍵

鍵の種類

メタデータ

利用サービス

鍵管理ポリシ

鍵管理の役割侵害からの回復

セキュリティ制御

システムテストと保証

鍵の管理

鍵の用途鍵の有効期間

鍵の危殆化

※ここで言う「鍵」は「鍵発行用データ（Keying Material）」を含んでいます。

暗号アルゴリズムと鍵サイズ

鍵の状態と遷移

鍵管理のフェーズ

相互運用性と移行

鍵管理システム

災害復旧監査

鍵の情報

鍵の保証

鍵の保護

鍵の確立

バックアップ

アーカイブ

鍵とメタデータの関連付け

管理機能運用

IDと強く関連してくるところ


対称鍵、公開鍵、プライベート鍵

一時鍵/静的鍵

鍵の種類

メタデータ

利用サービス

鍵管理ポリシ

鍵管理の役割侵害からの回復

セキュリティ制御

システムテストと保証

鍵の管理

鍵の用途鍵の有効期間

鍵の危殆化

暗号アルゴリズムと鍵サイズ

鍵の状態と遷移

鍵管理のフェーズ

相互運用性と移行

鍵管理システム

災害復旧監査

鍵の情報

鍵の保証

鍵の保護

鍵の確立

バックアップ

アーカイブ

鍵とメタデータの関連付け

管理機能運用

2013/8/29

鍵の状態と遷移（一般論、SP800-57）（Key States and Transitions）


有効化前（Pre-Activation）

有効（Activate）

一時停止（Suspended）

失効（Revoked）

無効化（Deactivated）

危殆化（Compromised）

廃棄（Destroyed）

危殆化後廃棄（Destroyed

Compromised）

※「一時停止」と「失効」はSP 800-57にはなく 800-130に登場

2013/8/29

鍵の状態とフェーズ


有効化前有効

一時停止

失効

無効化

危殆化

廃棄

危殆化後廃棄

運用前フェーズ

運用フェーズ

運用後フェーズ

廃棄フェーズ

管理フェーズもID情報とプライベート鍵でそれぞれある

依存関係を調べなければならない

2013/8/29



運用視点









アプリ開発者への参入障壁を下げるため

RFC 5408


KGCが持つ2つの機能を規定

公開パラメータ検索（Public Parameter Lookup）

プライベート鍵要求プロトコル（Private Key Request Protocol）

• HTTP GETアクセス• TLSの利用（TLS1.2以降のサポート）• パラメータの記載法：ASN.1(DER) ＋ BASE64• MIMEタイプ：application/ibe-pp-data

• HTTP POSTアクセス• TLSの利用（TLS1.2以降のサポート）• リクエストとレスポンスはそれぞれXML• MIMEタイプ：application/ibe-key-request+xml,

application/ibe-pkg-reply+xml

• レスポンスの種類は7つ（後述）• XML内のalgorithmOID, ibeIdentityInfo, が

ASN.1(DER)＋BASE64• クライアントの認証が必要：ベーシック認証対応

必須、Digest認証対応推奨

ID利用時の鍵（Private Key）を生成する鍵生成センタ（KGC）の開発

• 3種類のKGCを開発• Windowsベース＜１＞

• Windows Web Server 2008、.NET ASP、C#

• ηTペアリング、標数3

• Windowsベース＜２＞• Windows Web Server 2008、Tomcat、Java

• ηTペアリング、標数2

• Linuxベース• Linux （Cent OS）、php、C（pbc library）

• Tateペアリング、標数p

• 標準仕様をベース（RFC 5091、5408）• 一部異なる

• ペアリング方式、利用曲線、仕様のミスの修正

• 利用IBEアルゴリズムはBB1

2013/8/29 50次世代セキュア情報基盤ワークショップ

Windows/Linuxシステムの共通仕様：応答

• 7つの応答がRFC 5408では規定されている

• 試作システムではIBE 100、301、304のみを実装

2013/8/29 51

Response Code 意味実装

IBE100 KEY_FOLLOWS ○

IBE101 RESERVED ×

IBE201 FOLLOW_ENROLL_URI ×

IBE300 SYSTEM_ERROR ×

IBE301 INVALID_REQUEST ○

IBE303 CLIENT_OBSOLETE ×

IBE304 AUTHORIZATION DENIED ○

次世代セキュア情報基盤ワークショップ

Windows/Linuxシステムの共通仕様：認証

• 仕様上、認証の方法は2種類が可能• HTTPのヘッダを使って認証

• RequestのXML内に認証データを書いて認証

• 本システムではHTTPヘッダを利用したベーシック認証だけ実装


プライベート鍵要求の処理


Linuxシステムのパフォーマンス評価


OS CentOS 6.0

CPU Intel(R) Xeon(R) CPU E31280 3.5GHz

Memory 16GB

Kernel Linux 2.6.32-71.el6.x86_64

Software gcc 4.4.4Java SE build 1.7.0_01-b08 OpenSSL 1.0.0

Apache Benchmark(ab) を用いて測定同一サブネット内ホストからTAサーバにアクセス同時アクセス数を1~12に変化させ、プライベート鍵発行リクエストを行う同時アクセス×100回のリクエストを発行し、その処理時間を比較する

Linuxシステムのパフォーマンス評価


１秒あたりのリクエスト処理数リクエストの処理時間累積分布

同時アクセス数



運用視点









身近なSSLへ適用をすることで応用シーン検討を促進するため

IBEのSSL/TLS利用


鍵交換認証暗号化メッセージ

ダイジェスト暗号

スイート

IBE利用箇所

ClientHello

ServerHello

CertificateServerKeyExchange

CertificateVerify

ChangeCipherSpec

Finished

ChangeCipherSpec

Finished

Client Server

CertificateRequestServerHelloDone

Certificate

ClientKeyExchange

Application Data

ClientHello

ServerHello

CertificateServerKeyExchange

CertificateVerify

ChangeCipherSpec

Finished

ChangeCipherSpec

Finished

Client Server

CertificateRequestServerHelloDone

Certificate

ClientKeyExchange

Application Data

従来のハンドシェイク IBE適用ハンドシェイク

公開鍵証明書関連のプロセスを省略

鍵交換ができたことにより認証がされたとする「暗示的認証」

OpenSSL拡張部

• 暗号スイートの追加• BB1を利用可能にするスイートを追加

• 暗号プリミティブとしての利用• BB1インラインコマンドの新設

• プライベート鍵生成：genbb1

• 公開パラメータ生成、暗号化、復号：bb1

• 通信プロトコルとしての利用• TLS通信部分の拡張

• 通信コマンド（s_server, s_client）


OpenSSL拡張部：追加暗号スイート


スイート名鍵交換認証暗号メッセージダイジェスト

BB1-DES-CBC3-SHA Kx=BB1 Au=BB1 Enc=3DES (168) Mac=SHA1

BB1-RC4-SHA Kx=BB1 Au=BB1 Enc=RC4 (128) Mac=SHA1

BB1-AES128-SHA Kx=BB1 Au=BB1 Enc=AES (128) Mac=SHA1

BB1-AES256-SHA Kx=BB1 Au=BB1 Enc=AES (256) Mac=SHA1

OpenSSL拡張部：genbb1コマンド

• IDに対するプライベート鍵を生成する

• パラメータと引数（下表）

• 利用例

$ openssl genbb1 -ssin s_secret.txt -id www.example.com -informat -paramin param.txt -outformat -out skey.dat -pairingin e.param


パラメータと引数説明

-paramin filename 公開パラメータファイルを読み込む

-ssin filename KGCサーバシークレットを読み込む

-id arg ユーザIDを指定

-out filename プライベート鍵の出力先ファイル名を指定

-pairingin filename PBCライブラリで利用するパラメータファイルを読み込む

-inform, -outform RFC対応フォーマットとして入力/出力する

OpenSSL拡張部：bb1コマンド（１）

• 公開パラメータ生成、暗号化、復号を行なう

• パラメータと引数（右表）



-ssin filename KGCサーバシークレットを読み込む

-pairingin filename PBCライブラリで利用するパラメータファイルを読み込む

-paramin filename 公開パラメータファイルを読み込む

-csin filename ユーザプライベート鍵をファイルより読み込む

-out filename 出力先ファイルの指定

-host arg KGCのホスト名を入力する

-path arg KGCのパスを入力する

-id arg ユーザIDの指定

-authid/-authpswd 認証のためのID/パスワードの入力

-setup 公開パラメータの生成を行なう

-keyreq プライベート鍵の生成をKGCにリクエストする

-encrypt 暗号化を行なう

-verify 正当な鍵ペアであるかを検証する

-inform, -outform RFC対応フォーマットとして入力/出力する

OpenSSL拡張部：bb1コマンド（２）

• 利用例• 公開パラメータの生成

$ openssl bb1 -setup -ssin s_secret.txt -out params.txt -pairingin e.param

• 暗号化

$ openssl bb1 -encrypt -pubin -inkey id_data -paraminparam.txt -out cipher.txt -pairingin e.param

• 復号

$ openssl bb1 -verify -pubin -inkey id_data -paraminparam.txt -csin c_secret.txt -pairingin e.param


OpenSSL拡張部：s_serverコマンド

• HTTPSサーバとして動作するコマンド

• 追加パラメータ（下表）

• 利用例

$ openssl s_server -accept port -bb1param bb1pub.param -bb1key priv.key -cipher BB1-AES256-SHA



-bb1param filename 公開パラメータを読み込む

-bb1key filename プライベート鍵を読み込む

OpenSSL拡張部：s_clientコマンド

• HTTPSクライアントとして動作するコマンド

• 追加パラメータ（下表）

• 利用例

• $ openssl s_client host:port -cipher BB1-AES256-SHA -bb1param bb1pub.param



-bb1param filename 公開パラメータを読み込む

Apache HTTP Serverの拡張

• Apache HTTP ServerによるHTTPS通信はmod_sslモジュールを媒介したOpenSSL利用が主

• mod_sslにIBE対応OpenSSLを適用し、ApacheでのSSL/TLS通信にIBEを利用可能に

• apache設定ファイルでIBE利用のためのディレクティブを利用可能にするよう拡張

• 拡張ディレクティブ#BB1 Public Parameters

SSLBB1paramFile “公開パラメータへのパス”

#BB1 Private Key

SSLBB1privatekeyFile “プライベート鍵ファイルへのパス”




運用視点









KGCの位置づけを権威→一般ユーザに変えると必要になるアプローチ

KGC機能をユーザサイドに組み込む


権威（Authority）としてのKGC

ユーザ側機能としてのKGC

「豊富なリソースを持つ」と前提されてきた

• リソースは制限される• 機器が送信者となると、さらにリ

ソースの制限が起きる

限られたリソース環境においてどれだけ「送信者」としての負担がかかるかの評価が必要

PocketKGC：小型LinuxサーバでKGCを開発

• 送信者機能で通常作業として行なわれる作業は2種類

• KGC機能としての鍵発行

• 暗号文作成者機能としての暗号化

• 後者は省リソースの環境での研究は行なわれている

• 前者は十分な評価実績がない


送信者


プライベート鍵生成

（復号者認証）


データ暗号化

KGC

暗号文作成者

こちらの省リソース環境による研究は行なわれている

こちらの省リソース環境での研究は盛んではない

小型Linuxサーバ OpenBlockS 600にKGCを実装

次世代セキュア情報基盤ワークショップ 692013/8/29

製品名 OpenBlockS 600 （ぷらっとホーム）

寸法 81(W) x 133(D)x 31.8(H) mm

重量 265 g

NIC 1GbEx2

その他 CFカードにOSを搭載

OS SSD/Linux 0.5

CPU AMCC PowerPC 405EX

CPU周波数 600MHz

メモリ 1GB

Kernel Linux 2.6.29

Software JRE 1.5.0_16b00Tomcat 6OpenSSL 1.0.0PBC Library 0.5.8GMP Library

PocketKGC：プライベート鍵発行


PocketKGC：暗号化


0

500

1000

1500

2000

2500

3000

0

0.5

1

1.5

2

2.5

3

processing time

xml size

Android端末（Nexux7）でのIBEの実装

• TEPLAを利用

• Java化を行うためにJNI（Java Native Interface）でラッピング

• ラッピングをしてTEPLA＋JavaでIBEを実現する法は大きく2通りに分けられるが、拡張を考え後者を選択

• IBEの各機能（マスター鍵生成、クライアント鍵生成、暗号化、復号）をC言語で実装し、その関数を呼ぶインターフェースをJNIで作成

• TEPLAの各関数を呼ぶインターフェースをすべて作り、JavaでIBEの各機能を実装


機能

• 3者（KGC、送信者、受信者）を設定

• 各2者間や各ユーザの作業をボタンで表示

• 作業の例• マスターシークレット生成（KGC）• 暗号化（送信者）• 鍵発行リクエスト（受信者）• 復号（受信者）

• 通信について• ローカル端末内で1つのプログラム上

でデータのやり取り• 通信部分は未検討、未実装

• KGCマスターシークレットの扱い• クライアント側へのプライベート鍵発

行後のKGCマスターシークレット変更可能


その他の画面（１）


2種類のデータから成るマスターシークレット

暗号化されたデータ

KGCより発行されたプライベート鍵（復号鍵）

その他の画面（２）


マスターシークレットや（暗号化）データをタップするとデータが表示される



運用視点









OpenID Connectを用いて外部ID基盤の属性情報の利用

ロール：RAが外部サービス


送信者

受信者

暗号文FI

公開パラメータ

プライベート鍵

認証/認可

KGC NKGC 2

KGC 1DomainIF 1

RADomainIF

2

Domain 1

Domain 2

RFC5408 対応

暗号化ファイルアップロードアプリケーション


User Service Provider

属性情報発行認証＆認可確認

復号リクエスト

属性はFacebook上の属性３種類性別 “男性”, ”女性” 大学経歴 “有”, “無” 大学院経歴 “有”, ”無”

アップロードファイル暗号化依頼

処理シーケンス


ServiceProvider

ID Provider

１. ファイル復号依頼

７. 属性情報

１０. DocX

User

３. 認証/認可

２. トークン要求

４. Access token, ID token

６. 属性情報要求５. ID token検証

９. 復号

８. プライベート鍵生成

OpenIDConnect

動作画面


トップページ認証・認可のリクエスト



運用視点









IDベース暗号アプリ開発に利用可能な機能をまとめて、応用アプリの発展を促進

TEPLA概要

• 正式名称• University of Tsukuba Elliptic Curve and Pairing Library

• C言語のソフトウェアライブラリ

• 設計思想• 幅広いプラットフォームで利用可能なライブラリ

• プラットフォーム依存性を排除

• 利用しやすい形式・ライセンスでの配布• オープンソース

• 修正BSDライセンス（三条項ライセンス）

• 独自の計算アルゴリズムは適用しない


TEPLA：提供機能

• 254ビット素体、2次・12次拡大体上の元の演算• 加算、減算、積、逆元、2乗、平方根、べき乗、フロベニウス写像、

ランダムな元の生成

• Barreto-Naehrig（BN）曲線上の点の演算• 加算、スカラ倍算、フロベニウス写像、ランダムな点の生成、任意の

データの曲線上の点へのマッピング

• BN曲線上のOptimal Ateペアリング演算


TEPLA：各演算に用いられたライブラリや手法

• 有限体上の元の演算• 素体

• GMPライブラリ

• 拡大体• BeuchatらのPairing2010論文のアルゴリズム

• 楕円曲線上の点の演算• スカラ倍算

• Hankersonらの書籍 “Guide to Elliptic Curve Cryptography” に載っている手法

• NogamiらのIEICE論文 “Scalar Multiplication Using Frobenius Expansion over Twisted Elliptic Curve for Ate Pairing Based Cryptography” の手法

• MapToPoint（任意データの曲線上の点へのマッピング）• IEEE P1363.3 ドラフトに載っている手法

• ペアリング演算• BeuchatらのPairing2010論文のアルゴリズム


TEPLA：動作確認済み環境

• Windows 7 Professional SP1 (64bit) + Visual C++ 2010 (Visual Studio 2010 Professional) + MPIR 2.6.0 + OpenSSL 1.0.1c

• Linux (Kernel 2.6.18-308.8.1.el5) + gcc 4.1.2 + GMP 5.0.5 + OpenSSL 0.9.8e-fips-rhel5

• Mac OS X 10.6.8 (Snow Leopard) + gcc 4.2.1 + gmp5.0.4 + OpenSSL 0.9.8r


性能評価

• PBC Libraryとのパフォーマンス比較• Linux上で計算

• PBCライブラリの各パラメータとTEPLA

• プラットフォームごとのパフォーマンス比較• Windows 7、Linux、Mac OS X

• 詳細環境は「動作確認済み環境」と同じ

• ペアリング、スカラ倍算、MapToPoint、12次拡大体上の点のべき乗


PBC Libraryのパラメータ

タイプ説明 Param名称

Type A y^2=x^3+x512ビット素体と1024ビット素体の2つが利用可能

a, a1

Type B y^2=x^3+xq = 2 mod 3 となる素数qについての素体

（未実装）

Type C y^2=x^3+1, y^2=x^3+2x-1標数3の拡大体

（未実装）

Type D MNT曲線基礎体サイズが159ビット、201ビット、224ビットのものが利用可能

d159, d201, d224

Type E Complex Multiplication (CM) 手法を用いて楕円曲線を構成。1024ビット有限体を用いた方式が利用可能

e

Type F BN曲線。基礎体サイズが160ビットのものが利用可能。 f

Type G CM手法を用いて楕円曲線を構成しているが、TypeEとは異なる構成。Freemanにより発見された曲線。基礎体149ビットのものが利用可能

g149


PBC Libraryとの比較：ペアリング


PBC Libraryとの比較：スカラ倍算


PBC Libraryとの比較：MapToPoint


PBC Libraryとの比較：12次拡大体上の点のべき乗演算


PBC Libraryとの比較：各データ

a a1 d159 d201 d224Pairing: 2.207847 64.1451938 4.837811987 7.307548 9.032555ScalarMultiplication: 2.559117 55.4810421 0.769784262 1.102317 1.463203MapToPoint: 5.896012 2.63943062 0.056493633 0.213672 0.202034PowOnGT: 0.266692 5.20824593 1.426518647 2.082603 2.583897

e f g149 TEPLAPairing: 9.084011 25.3031 14.62994 6.398042ScalarMultiplication: 6.512432 0.769841 0.691222 0.683685MapToPoint: 34.49245 0.032047 0.033579 0.308104PowOnGT: 0.285336 5.784836 4.027521 6.673064

単位はmsec


プラットフォームごとの比較

Lin Win MacPairing: 6.398042 3.2313966 3.561012154ScalarMultiplication in G1 0.683685 0.35382145 0.36199902ScalarMultiplication in G2 1.319883 0.65504598 0.719650527MapToPoint on G1 0.308104 0.16614596 0.166285759PowOnGT: 6.673064 3.24932985 3.613305311

単位はmsec

Linux : Intel Core i7 920 (2.67GHz), 6GB RAMWin : Intel Core i7 3960X (3.30GHz) 8GB RAMMac : Intel Core i7 2820QM (2.30GHz) 8GB RAM

ハードウェアスペック


TEPLAでのIBE実装：BF

• LinuxでIBEをTEPLAを用いてテスト実装• BF方式

• プラットフォーム• OS : Linux (Ubuntu)

• CPU : Intel Celeron G530 (2.4GHz)


演算種類実行時間（msec) 備考

Setup 3.257 ランダム点の生成x1、スカラ倍算x1

Extract 1.722 MapToPoint（G1）x1、スカラ倍算x1

Encrypt 10.931MapToPoint（G1）x1、ペアリングx1、スカラ倍算x1、べき乗剰余（GT）x1

Decrypt 4.356 ペアリングx1

まとめ


自己紹介：なぜこういったアプローチを取っているか







idベース暗号の概観と今後の展望（次世代セキュア情報基盤ワークショップ...

Documents