1

認証の重要性とその技術

土井洋(中央大学研究開発機構/情報セキュリティ大学院大学)

1. 認証の概要2. メッセージ認証3. 相手認証

① サーバ(TTP)を利用② 事前共有情報を利用

③ 公開鍵暗号系を利用

4. その他のトピックス

中央大学情報セキュリティ人材育成公開講座

2006/8/23 2

1. 認証の概要• シュメール人の円筒印章[B.C.3300]• 中国の印章[B.C.480-221]• 合言葉・・・・世界各地で使われた．• パスワード認証････様々なコンピュータ(かなり初期から)使われていた．

タイムシェアリングシステム，マルチユーザシステム

• OECD情報セキュリティのためのガイドライン– 1992年：OECD Guidelines for the Security of Information Systems– 可用性(Availability)，機密性(Confidentiality)，完全性(Integrity)

• セキュリティの概念整理に意味がある．

• OECD暗号政策に関するガイドライン– 1997年:Guidelines for Cryptography Policy

• 認証，完全性の記述がある．

佐々木，宝木：印鑑と電子印鑑の歴史と類似性の分析 ，情報処理学会論文誌, Vol.42, No.8, pp.1968-1974, 2001.

2

2006/8/23 3

完全性：OECD情報セキュリティガイドライン

• OECD情報セキュリティガイドライン(1992)– "integrity" means the characteristic of data and information being

accurate and complete and the preservation of accuracy and completeness.

– 完全性：データ及び情報が正確（accurate）で完全（complete）であり，かつ正確さ（accuracy），完全さ（completeness）が維持されること

http://www.oecd.org/document/19/0,2340,en_2649_34255_1815059_1_1_1_1,00.htmlhttp://www.ipa.go.jp/security/fy14/reports/oecd/oecd-security.pdf

2006/8/23 4

認証，完全性：OECD暗号政策ガイドライン

• OECD暗号政策に関するガイドライン(1997)– "Authentication" means a function for establishing the validity of

a claimed identity of a user, device or another entity in an information or communications system.

– 認証とは，情報通信システムにおいて，ユーザ，装置又はその他の主体が主張する自己同一性が正当であることを確証する機能をいう．

– "Integrity" means the property that data or information has not been modified or altered in an unauthorised manner.

– 完全性とは，データ又は情報が権限のない方法により修正又は改竄されていないという特性をいう．

http://www.oecd.org/document/11/0,2340,en_2649_34255_1814731_1_1_1_1,00.htmlhttp://www.isc.meiji.ac.jp/~sumwel_h/doc/intnl/recm_crypt.htm

3

2006/8/23 5

(本講座で扱う)認証とは･･･• メッセージ認証

– データの正当性(改ざんされていないこと)の確認• 相手認証(エンティティ認証)

– 相手の正当性(なりすましされていないこと)の確認

• 例– メッセージ認証

• MAC– 相手認証

• パスワード認証，バイオメトリクス認証– 両方

• 電子署名(メッセージ認証と相手認証を兼ねている)

2006/8/23 6

認証の重要性

• 電子化・ネットワーク化されたシステム– 相手が誰であるかが保障されないと･･･– 通信内容の正当性が保障されないと･･･

• 極論(以下のアプリのうち，ありそうなのは?)– 「守秘」は不必要だが，「相手認証とメッセージ認証」が必要なアプリ

– 「相手認証やメッセージ認証」は不必要だが，「守秘」が必要なアプリ

ビジネスなどは

そもそも

成り立たない?

4

2006/8/23 7

様々な”認証”方式

• 相手認証– 免許証← 類似のものは現実社会で古くから利用されている

– WindowsやUnixシステムを利用する際のログイン– Web (ID，パスワード)– バイオメトリクス認証(銀行，パスポート)

• メッセージ認証– (電子署名を利用する/電子商取引などの)アプリ

• 利用者はほとんど意識する機会がない･･･縁の下の力持ち．

2006/8/23 8

パスワード認証

① 事前にBさんの持つDBにAさんのパスワードを登録② Aさんという名称とパスワードを送る③ パスワードDBに登録されていれば，Aさんと認める．

A: 3141

Aさん

BさんA :3141

A :3141 A: 3141B: 2718C: 1414

パスワードDB

この人Aさんね

5

2006/8/23 9

パスワード認証の問題点

• パスワードDBを解析する– パスワードDBにパスワードそのものを保存しない(ハッシュ値保存)

• ネットワーク上を流れるパスワードを解析する– 暗号/一方向性関数による処理を行う

• ネットワーク上を流れるパスワードを再利用する– 毎回異なるデータが流れるようにする

Aさん

Bさん

A: 3141B: 2718C: 1414

パスワードDB

A: 3141B: 2718C: 1414

A :3141

攻撃者様々な攻撃

2006/8/23 10

相手認証の分類

• 利用者の知識による認証– パスワード

• 利用者の所持品による認証– クレジットカード– 磁気カード

• 利用者の身体的特徴による認証– 指紋，静脈･･･バイオメトリクス認証

ユーザの知識=秘密情報(Long term)セッション鍵(Short term)

秘密の値(ユーザの知識に相当)を得た後，認証プロトコルを行う

6

2006/8/23 11

準備(共通鍵暗号)• 共通鍵暗号アルゴリズムE,D

– 暗号化アルゴリズムEは公開されている．• 入力：鍵とメッセージ，出力：暗号文．

– 復号アルゴリズムDも公開されている．• 入力：鍵と暗号文，出力：復号結果(=メッセージ)．

• C=EK(M)またはC={M}K– メッセージMの鍵Kによる(共通鍵)暗号文．

• DK(C)– 暗号文Cの鍵Kによる(共通鍵)復号結果．

• DK(EK(M))=M AESが現在の標準

2006/8/23 12

準備(公開鍵暗号)• 公開鍵暗号アルゴリズムE,D

– アルゴリズムEは公開されている• 入力：公開鍵とメッセージ，出力：暗号文．

– アルゴリズムDも公開されている• 入力：秘密鍵と暗号文，出力：復号結果(=メッセージ)．

– 鍵が2種類ある：公開鍵(PK)，秘密鍵(SK)• C=EPK(M)

– メッセージMの公開鍵PKによる暗号文．• DSK(C)

– 暗号文Cの秘密鍵SKによる復号結果．

• DSK(EPK(M))=M RSA，(楕円)ElGamal暗号などを基本とする方式は多々ある．

7

2006/8/23 13

準備(電子署名)• 署名生成，検証アルゴリズムSig, Ver

– アルゴリズムSigは公開されている• 入力：秘密鍵とメッセージ，出力：署名．

– アルゴリズムVerも公開されている• 入力：公開鍵，メッセージ，署名，出力：Yes/No．

– 鍵が2種類ある：公開鍵(PK)，秘密鍵(SK)• S=SigSK(M)

– メッセージMの秘密鍵SKによる署名．• VerPK(M,S)

– メッセージM，署名Sの公開鍵PKによる検証結果．

• VerPK(M,SigSK(M))=Yes RSA，(楕円)ElGamal署名などを基本とする方式は多々ある．

2006/8/23 14

2.メッセージ認証

攻撃者文書の中身を書き換える

MAC： Message Authentication Code / メッセージ認証コード

TAG

TAG

TAG??

鍵を持たずに･･･

攻撃者受理されるメッセージ，TAGを作る

鍵を持たずに･･･

8

2006/8/23 15

メッセージ認証の設計目標

• 目的– メッセージが外部の者により改ざんできない．

• 前提– 送受信者は秘密の情報を共有している．

• 秘密の情報を利用して認証するために必要なデータ(TAG)をメッセージに付加する．

• 達成目標– [攻撃者]相手に受理される未出の(メッセージ，TAG)を作る．– [設計者]相手に受理される場合は，TAGを正しく作った場合に限る．

• 考慮すべき攻撃– 攻撃者は，(メッセージ，TAG)を好きなだけ得られる．

2006/8/23 16

MACの実現例(CBC-MAC)

ODAY．△FINE △TIT △ IS △

M3M2M1

EK1

⊕

EK1

⊕

TAGEK1

送信者と受信者が，1つの秘密鍵K1を事前に共有している

CBC-MACはメッセージが固定長の場合，安全．可変長の場合，偽造可能．

9

2006/8/23 17

CBC-MACに対する攻撃(1/2)

• CBC-MACはメッセージが可変長の場合，偽造可能であることを示す．– 具体的には，敵は(M1, TAG)を入手すると， ((M1,M1

TAG), TAG)を構成できる(これは受理される)

0

a aa a

bb

bb

⊕ ⊕= ⊕ ⊕= ⊕=

利用する性質

⊕

2006/8/23 18

CBC-MACに対する攻撃(2/2)• 入手済みのデータ(M1,TAG)

– 実はTAG=EK1(M1)であることに注意．• 偽造データは((M1, M1 TAG), TAG)

– このことを，CBC-MACの図を用いて確認する．

EK1

⊕

EK1

M1 TAGM1

EK1(M1)

ここの排他的論理和はEK1(M1) M1 TAG

EK1(M1) M1 TAG

=TAG M1 TAG

=M1M1

EK1(M1)

最終的な出力はEK1(M1)=TAG

⊕⊕

⊕

⊕⊕⊕⊕

⊕

10

2006/8/23 19

MACの実現例(EMAC)

ODAY．△FINE △TIT △ IS △

M3M2M1

EK1

⊕

EK1

⊕

TAG

EK1

EK2

送信者と受信者が，2つの秘密鍵K1とK2を事前に共有している

NESSIEでリストアップされたものの1つ

2006/8/23 20

MACに関するトピックス

• MACの標準化– NESSIEでリストアップされたもの

• EMAC: 前頁参照のこと• そのほか，UMAC，TTMAC，HMAC

– 米国政府の標準(2003年)• CMAC(OMAC): 岩田先生&黒澤先生により提案された方式

http://www.cryptonessie.org/

http://csrc.nist.gov/CryptoToolkit/modes/http://www.nuee.nagoya-u.ac.jp/labs/tiwata/omac/omac.html

11

2006/8/23 21

3.相手認証• 目的

– (通信相手)を正しく認証する．• 前提

– [パターン1]信頼できるサーバが存在し，利用できる．– [パターン2]送受信者は秘密の情報を事前に共有している．– [パターン3]公開鍵暗号系を利用する．

• 達成目標– [攻撃者](認証されてはならないのに)認証される．– [設計者]認証に対する攻撃や妨害に(少なくとも)気付く．

• 攻撃– 攻撃者は，認証に伴うすべてのデータを見ること/改変することができ

る．– 攻撃者は，自ら(通信相手のふりをして)データの送受信をすることが

できる．

2006/8/23 22

相手認証の考え方(と攻撃)

• 攻撃者の目標=Aさんへのなりすまし– AさんのふりをしてBさんと約束する．– Aさんのふりをして様々なサービスを受ける．

私はAだ

私はAだ

攻撃者様々な攻撃

私はAだ

この人はAさんよね．

Aさん Bさん

12

2006/8/23 23

鍵共有と併用する場合

• 認証終了時に(一時的な)鍵Kを共有する– 鍵Kを持っている人は(認証された)相手だけ．– 以後，共通鍵暗号+MACで秘匿+認証可能．– 取引の証拠を残す必要があるときは署名が必要．

私はAだ

私はAだ

私はAだ

Aさん Bさん

ではAさんと取引に入ろう．

取引に関するデータ(鍵Kによる暗号化)

K K

2006/8/23 24

何が脅威か(攻撃例)

• 認証(+鍵共有)の脅威について– シンプルな(実はセキュアでない)構成を示し，– 上記構成に対する攻撃例を示す．

Boyd, Mathuria “Protocols for Authentication and Key Establishment, Springer

Smith(稲村監訳) “認証技術：パスワードから公開鍵まで”，オーム社

認証+鍵共有の構成(なぜこのような構成が必要か?)を示すために，使われるスタイル

暗号・セキュリティの講義で使われがちなスタイルの例

13

2006/8/23 25

3.① サーバを利用するモデル• 各エンティティ(AやB)は信頼できるサーバSとのみ鍵を共有している．– 各エンティティ同士(例えばAとB)は鍵を共有していない．

• 信頼できるサーバSは，各エンティティのリクエストに応じて(セキュアに)動作する．– いつでも(初期化時のみではなく)利用できる．

• 「サーバを信頼できれば安全」な方式を目指す– 共有している鍵をきちんと管理している(漏洩しない)．– サーバはプロトコルどおりに動作する．

2006/8/23 26

認証+鍵共有プロトコル1

• AとBはSが生成した鍵(単なる乱数)KABを共有する．• 鍵KABはSとA(SとB)しか知らない鍵で暗号化

S

A B

{ } ,

{ }AS

BS

AB K

AB K

K

K

①

②

③ { } ,BSAB K

K A

A,B

KAS：AとSとの共有鍵

KBS：BとSとの共有鍵

14

2006/8/23 27

攻撃1(認証+鍵共有プロトコル1)

• AはBと鍵KABを共有したつもり．• BはDと鍵KABを共有したつもり．

S

A B

{ } ,

{ }AS

BS

AB K

AB K

K

K

①

②

③ { } ,BSAB K

K AC

③ { } ,BSAB K

K D

A,B

2006/8/23 28

攻撃2(認証+鍵共有プロトコル1)

• AはBと鍵KACを共有したと思い込む．• 実は，AはCと鍵KACを共有している．

S

A C{ } ,{ }

CSASAC K AC KK K

①

④

⑤ { } ,CSKAC

K A

C{ } ,{ }

AS CSAC K AC KK K③

② A,C

A,B

15

2006/8/23 29

得られた知見(その1)

• エンティティ間への割り込み– データを攻撃者が改変できる．– データを(改変しつつ)中継する– これらは強力な攻撃．

• 攻撃はなりすましだけではない．– サービス妨害に近い攻撃も考えられる．– 攻撃1は「なりすまし」は達成していないが，実害はある．

2006/8/23 30

認証+鍵共有プロトコル2

• AとBは鍵KABを共有する．• 鍵KABはSとAまたはBしか知らない鍵で暗号化=信頼できる• 暗号文の中に相手名が含まれている=攻撃は困難?

S

A B

{ , } ,

{ , }AS

BS

AB K

AB K

K B

K A

①

②

③{ , } ,BSAB K

K A A

A,B

16

2006/8/23 31

攻撃(認証+鍵共有プロトコル2)

• AとBは鍵K’ABを共有していた(かなり以前に使った鍵)– 以前利用した鍵の情報は漏れている(Cに知られている)場合がある．– 攻撃者Cは以前利用した鍵を攻撃のため再利用する可能性がある．

• Cは以前入手していたK’ABとそのときの通信を利用してAになりすますことや (セッション鍵を利用して)盗聴できる．

C

A B

A,B'

'

{ , } ,

{ , }AS

BS

AB

A KB

KK B

AK

①

②

③'{ , }

BSAB KK A

2006/8/23 32

得られた知見(その2)• 一時的に作った鍵を盗まれる場合を想定したほうがよい．

– 鍵の格納場所，取り扱い方により盗難可能性が異なる．– 格納場所は耐タンパーデバイスか，通常メモリか?

• 以前のセッション鍵のみならず，そのときの通信履歴を攻撃者は所有しているかもしれない．

• エンティティ(A，B)は，以前使った鍵を永遠に記憶できるわけはない．– もし記憶できればBは「過去に一度でも利用したセッション鍵を割り当

てられそうになったら拒否」すればよい．

17

2006/8/23 33

認証+鍵共有プロトコル3

• AとBは鍵KABを共有する．• 鍵KABはSしか知らない鍵で暗号化=信頼できる• ④，⑤で共有していることを確認する．

S

A B

{ , , ,{ , } }BS ASAB A AB K K

K B N K A① ②

③ { , }BSAB K

K A

A,B,NA

④ { } ABB KN

⑤ { 1}ABB K

N −

Needham-Schroederプロトコル(1978)

2006/8/23 34

Needham-Schroederプロトコル

• 認証+鍵共有プロトコルの出発点– 過去のセッション鍵を利用する攻撃には弱い．

• この変形は様々なところで使われていた．– Kerberos(MITのAthenaプロジェクト(1983))

18

2006/8/23 35

3.② 事前共有情報利用モデル• 各エンティティ(AとB)はKABを事前共有している．

– KABは他のエンティティに漏れることはない．– この条件の下で(相互)認証(+セッション鍵の共有) を行う．

• 信頼するサーバの存在を仮定しない．– サーバの適切な運用は負担が大きい．– ただし， KABを事前共有することも負担は小さくない．

• 相互認証について考察し，攻撃例を考えてみる．

2006/8/23 36

相互認証プロトコル4

• AはBを認証する．– Aが作った乱数に(BまたはAしか作れない)値を作れるのはBだけだ．

• BはAを認証する．– Bが作った乱数に(AまたはBしか作れない)値を作れるのはAだけだ．

A BAN①

② 1, ( , ,...)B AB AN h K N

③ 1( , ,...)AB Bh K N

h1はハッシュ関数

19

2006/8/23 37

攻撃(相互認証プロトコル4)

A BBN③

④ 1, ( , ,...)A AB BN h K N

• 攻撃者CはBに対してはAのふり，Aに対してはBのふり• BはAとの相互認証に成功したと思っている．

– 実は，Cが認証相手．• AはBとの相互認証に失敗したと思っている．

– 認証プロトコルは途中で頓挫．

CN①

② 1, ( , ,...)B AB CN h K N

⑤ 1( , ,...)AB Bh K N

C

2006/8/23 38

得られた知見(その3)

• 攻撃者がエンティティ間に位置する攻撃の一例．– 別用途で利用可能なデータを生成しないように(③を工夫して)プロトコルを構成する必要がある．

A BAN①

② 1, ( , ,...)B AB AN h K N

③ 2 ( , ,...)AB BK Nh

例えば，ハッシュ関数h1，h2を複数用意すれば・・・・

20

2006/8/23 39

3.③ 公開鍵暗号系利用モデル• 各エンティティ(AやB)はPKIを利用できる．

– 相手の公開鍵を(正しく)得ることができる．– 信頼できるサーバは必要だが，認証・鍵共有時には必要ない．

• PKIを使えると何がうれしいか?– 電子署名を利用できる．

2006/8/23 40

認証プロトコル5

• AはBを認証する．– Aが作った乱数に(Bの)署名をできるのはBだけだ．

• (Bの)署名はPKIを利用することで，確認できる．

A BAN①

② ( )B ASig N

21

2006/8/23 41

攻撃(認証プロトコル5)

• AはBを認証したつもりになる．– Aが作った乱数に(Bの)署名をできるのはBだけだ．

• 実は，CはBのふりをしてAに正しく認証されている．

• BはCに認証されたつもりになる．

A BAN①

④ ( )B ASig NC

AN②

③( )B ASig N

2006/8/23 42

鍵共有プロトコル6

• DH鍵共有(鍵配送)として有名な方式– 公開鍵暗号，電子署名の概念と共に誕生– 認証は考えていない．

A BmodaAX g p=①

modbBX g p=②

*R pa Z∈① *R pb Z∈②

( )a b bAK g X= =( )b a a

BK g X= =

公開情報=素数p,生成元g

22

2006/8/23 43

攻撃(鍵共有プロトコル6)

• MITM攻撃として有名な例– AはBと，BはAと鍵共有していると思っている．– 実際は，AとC，BとCが鍵共有している．

• 鍵共有後に中継を続ければ，盗聴し放題．

A Ba

AX g=①

bBX g=

%%②

*R pa Z∈①

*R pb Z∈②

( )a b bBC AK g X= =%% %( )b a aAC BK g X= =

%% %

Ca

AX g=%%①

bBX g=②

,AC BCK K% %

( )ACK

E M% ( )ACK

E M% ( )BCKE M% ( )BCKE M%

2006/8/23 44

得られた知見(その4)

• エンティティ間への割り込み– データを攻撃者が中継(改変)すると，シンプルな認証プロトコル，鍵共有プロトコルは不具合が生ずる．

• 攻撃者が能動的に攻撃を行うという状況下での安全性の考察が必要･･･容易ではない– 実際，様々なプロトコルが提案されては攻撃されてきた．– 未知の攻撃によるもの，既知の攻撃によるものなど様々

23

2006/8/23 45

知見を総合すると･･･

• 安全性の定義は容易ではない．– とはいえ，いくつかのアプローチがある

• Matching Conversation

• 攻撃，達成目標も様々– MITM (Man in the Middle 攻撃)– サービス妨害に類する攻撃– Forward Secrecy

– ソーシャルエンジニアリング– スニッフィング(キーストロークなど)

2006/8/23 46

4.その他のトピックス

• ワンタイムパスワード• Forward Secrecy• 電子署名=メッセージ認証+相手認証• 署名と認証の関係

– 構成方法の類似性

24

2006/8/23 47

ワンタイムパスワード

• 毎回，ネットワーク上を流れるデータが異なる• データを1回だけ送ればよい．• データベース上の値(x1,x2)が毎回異なるので，データベース

への攻撃も無意味

利用者A利用者B

x2を事前登録

x1=h(x0), x2=h(x1)

x1 1回目の認証

x0 2回目の認証

x2=h(x1)?

x1=h(x0)?

x2

x1

ほかにも，クロックベースの方式もある．

2006/8/23 48

Forward Secrecy

• 秘密情報を長期間きちんと管理できるか?– 答えはおそらく「できない」だろう．

• 認証+鍵共有モデル– セッション鍵が漏洩することは覚悟していた．– しかし，ほかの秘密情報(Long Term Key)は漏洩しないモデルだった．

• 秘密情報が漏れた場合の影響を小さくしたい．– (既に生成した)セッション鍵の漏洩を避ける．

25

2006/8/23 49

認証+鍵共有(F. Sec.でない例)

• サーバSにセッション鍵KSを作ってもらう．• もし，AとSとの間の共有鍵KASが(ある日)漏洩すると

– (過去の)取引に関するデータが筒抜けとなる．

A B

S,A B①

{ , , }ASS K

A B K②

{ , , }BSS K

A B K③

取引に関するデータ

2006/8/23 50

認証+鍵共有(F. Sec を志向)

• サーバSに鍵KSを作ってもらう．• DHプロトコルを利用し，セッション鍵生成時にKSを利用する．• もし，AとSとの間の共有鍵KASが(ある日)漏洩しても…

– NAやNBは漏洩しない(既に存在しない)ので，(過去の)セッション鍵は漏洩しない．

A B

S,A B①

{ , , }ASS K

A B K③

{ , , }BSS K

A B K④

, ANA g②

, BNB g⑤ ( ) B SA N KNK g=( ) A SB N KNK g=

DHプロトコル

26

2006/8/23 51

電子署名=メッセージ認証+相手認証

• 電子署名の入出力– 入力：公開鍵，メッセージ，署名– 出力：Yes/No

• 相手認証：– 公開鍵を利用して検証結果(出力)=YESとなる場合，「署名を生成するのに秘密鍵を利用した」

• メッセージ認証：– 署名を生成するときに「メッセージ」を入力として使う．– 実はメッセージを1ビットでも修正すると，署名はまったく異なる値となる．(他人は1ビットたりとも改変できない)

2006/8/23 52

署名と認証の関係(Schnorr認証)

P(証明者)(秘密の情報x)

V(検証者)

(p,g,y)に対してy=g-x mod p となるxを知っている

a = gr mod p(r:乱数)

0< c ≦q-1をランダム

v= r+cx mod q a≡gv×yc (mod p)v

a

c

gの位数はq

27

2006/8/23 53

署名と認証の関係(Schnorr署名)

P(署名生成者)(秘密の情報x)

V(検証者)

(p,g,y)に対してy=g-x mod p となるxを知っている

a = gr mod p(r:乱数)c=h(M, a,…)

v= r+cx mod q c = h(M, gv×yc mod p,…)v

a

c

M

認証と署名が表裏一体な方式はたくさんある

gの位数はq

不要

2006/8/23 54

標準化について

• NIST– SP800-38B･･･CMAC– FIPS196

• IEEE P1363･･･公開鍵暗号系• NESSIE

– GPS(認証) • Schnorr認証とよく似ている．

– HMAC，UMAC，EMAC，TTMAC(いずれもメッセージ認証コード)• ISO/IEC

– 9797(メッセージ認証コード)– 9798(エンティティ認証)

• 1pass ～ 5pass の認証(TTPあり/なし)など– 11770(かぎ管理)

• 標準化動向の報告– 7月のCSEC+ISEC合同研究会などで報告されている．

• 信学技報ISEC2006-46(2006/7)，ISEC2005-30(2005/7)

28

2006/8/23 55

まとめ• 認証(+鍵共有)について

– 不具合が生じる例(脅威)を示した．– 署名と認証の関係を示した．

• 認証とは相手あっての話– 標準的なものを使うに越したことはない．

• （メッセージ，相手)認証の今後– フォーマルな安全性を示す方向で研究が進んでいる．

• 「○○攻撃を防ぐことができる」ではない．(いたちごっこではない)• 例えば，「未出の(メッセージ，TAG)を秘密鍵を持たずに構成できる確率は1/280未満」という証明が与えられた方式が主流になる．

• システムに組み込む場合– 標準化されているものについても，前提・仕様等をよく理解したうえで

利用しなくてはならない．