図面 (/)

この項目の情報は公開日時点(2016年9月5日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (14)

課題・解決手段

ユーザのための署名を生成するための方法とシステムが記載される。システムは、署名サーバと、ユーザのための初期処理デバイスと、ユーザのための有効性検証デバイスとを備える。初期処理デバイスは、第1のメッセージMを表示し、前記第1のメッセージMのための署名を生成するよう署名サーバに要求を送るよう構成される。署名サーバは、前記第1のメッセージMに基づいた第2のメッセージM’と、前記ユーザと前記署名サーバとの間で共有される第1の秘密とを用いて有効性検証チャレンジを生成し、前記有効性検証チャレンジを有効性検証デバイスに送るよう構成される。有効性検証デバイスは、前記第1の共有された秘密を用いて前記第2のメッセージM’を再生成し、前記第2のメッセージM’を表示し、表示された第2のメッセージM’が前記第1のメッセージMに対応することのユーザ確認を受け、署名を生成するために要求を確認する有効性検証コードを生成し、前記有効性検証コードを前記署名サーバに送るよう構成される。その後、署名サーバは、第1のメッセージMについてユーザのための署名を生成する。

概要

背景

デジタル署名概念がもたらされてから40年近くがたっても、依然、電子商取引(e-commerce)として知られるものにおいて、いくつもの課題が存在する。ゴールは、ドキュメント取引がユーザによってデジタル的に署名され、基礎をなすインフラ全体が、取引が電子化される前の数世紀の伝統的に受け入れられていたものの特性のほとんどを有する安全な法的フレームワークを提供するような仕組みである。
簡潔に言えば、主な課題は、以下のシステムを提供することである:
1)"What You See Is What You Sign"(あなたが見るものがあなたがサインするもの)または"WYIWYS"として知られているキャッチフレーズにおけるものを提供し、以下のような方法で、ユーザが"what he sees"(彼が見たもの)にサインしようと決めることを可能にする:
2)特定の取引またはドキュメント上のこの特定のデジタル署名が、特定のユニークに識別されたユーザの意思による行為で生成されたことの実体的で説得力のある証拠(特に、法的な意味で)を与えることが可能である。

"WYSIWYS"の概念は、Peter LandrockとTorben Pedersenによる「“WYSIWYS? What you see is what you sign?” Information Security Technical Report, Elsevier, Vol 3, No 2, 1998」に紹介された。

他の基本的な技術論文は、Fiat Shamirの「“How to Prove Yourself: Practical Solutions to Identification and Signature Problems” Advances in Cryptology, CRYPTO’86 Proceedings, Lecture Notes in Computer Science, Springer Verlag 1986」である。この論文は、電子データの確実な搬送に関連する以下の様々なスキームを定義している。
認証(authentication)スキーム:Aは、Bに対し、彼がAであることを証明できるが、他の誰も、Bに対し、彼がAであることを証明できない。
証明(identification)スキーム:Aは、Bに対し、彼がAであることを証明できるが、Bは、他の誰かに対し、彼がAであることを証明できない。
署名(signature)スキーム:Aは、Bに対し、彼がAであることを証明することができるが、Bは、彼自身にさえ、彼がAであることを証明できない。

認証スキームは、共有鍵を用いた対称暗号化技術を用いることによって可能である。ソフトウェアベースプロトコルにおいて、より強力な証明スキームは公開鍵技術を必要とした。これらの技術は、Aの秘密鍵が含まれたが、それは、彼の鍵が選ばれたコンテンツをもったメッセージに適用されることを必要としないことを証明する。いわゆるゼロ知識証明スキーム(zero-knowledge identification scheme)がこのカテゴリーにはいる。最後に、安全な署名スキームにおいて、これが可能である証明スキームとは反対に、基礎をなすプロトコルはBによってシミュレートされることができない。

署名スキームのための1つのコンセプトは、各ユーザが、マイクロチップを主とするスマートカードまたは署名スティック等のローカル署名生成デバイス上に記憶された彼の秘密鍵を持って回ることであった。このアプローチは、それがUSBポートおよび/またはスマートカードリーダー利用可能性、webベース環境におけるそのような周辺機器を使用することの不十分な適応可能性、および、古いデバイスと現代のデバイス、または、異なるブランドを有するデバイスの間の可能な互換性の問題を必要とするので、いくつかの重大な欠点を有する。また、ユーザが、可動性と使用の容易さの障害となる安全な場所に署名生成デバイスを保管することが不可欠である。このアプローチは、現実に、全国的規模の開発や高い利用率をもっていきわたらず、派生した開発は、少ないユーザをもった管理された環境に制限されている。

署名スキームのための代わりのアプローチは、欧州特許1364508に記載されている。このスキームは、秘密鍵の所有者が秘密鍵に対する唯一コントロールを保持することを保証するが、ユーザのための署名の生成のための秘密鍵を中央で記憶するセントラル(安全な)署名生成デバイスを用いる。このアプローチは、現在、例えば、デンマークノルウェイ、ルクセンブルグにおいて、ほとんど全ての市民ビジネス、および、公的サービス機関によって広く使用されている。

過去30年の間に、いくつかの他の商業的な解決策が発展し、アタックがますます精巧になってくるにつれて、ますます進歩している。安全性の低い解決策は、ユーザのみを特定しようとするがメッセージ自身の安全を守らない、ある程度のセッションセキュリティを与える解決策である。例えば、1つの初期の解決策は、メッセージとともに転送される静的なパスワードに依存し、最近の解決策は、メッセージとともに転送されるためのいわゆるOTP(One Time Password)(しかし、依然、メッセージの内容とは独立に生成される)に依存している。

スマートホン到来でもって、新たな機会の領域が出願した。これらは、例えば、欧州特許第1969880および欧州特許第1959374において利用されており、専用のハードウェアを用いて、実際に、認証と証明に関する上記2つの要件合致するが、かなり高価なハードウェアの使用を代償としている。

しかし、これらのアプローチのどれも、WYSIWYSの特性−声の確認または個別チャネルの使用等の更なる手段なくその目的にかなうことが重要である−を保証しない。

WYSIWYSの1つの強力な実現は、最もユーザフレンドリーではないにもかかわらず、Mastercardによって開発され、後にDPA(Dynamic Passcode Authentication)としてVisaによって採用された、CAP(Chip Authentication Program)であり、それは、スタンドアロンカードリーダーと、デビットまたはクレジットEMチップカードを必要とする。ユーザが、例えばワークステーション上で支払の明細を与えたら、彼は、かれのPINをキー入力し、「署名(Sign)」機能を選択することによって、かれのデビットカードまたはクレジットカードをカードリーダーに入れることを求められる。かれは、次に、支払われるべき額と受取人口座をキー入力することを要求され、メッセージ認証コード(message authorization code:MAC)が彼のデビットまたはクレジットカードによって生成され、カードリーダーに表示される。続いて、彼は、ワークステーション上での彼の取引とともにこれをキー入力する。

この背景にある暗号法は、支払カードバンクバックエンドとの間で共有される鍵をもちいた対称暗号化システムである。そして、これは、上述の定義でもって、「認証スキーム」であるように見える。しかし、支払カードとバンクバックエンド上の鍵が改竄防止ハードウェアによって保護されているので、これは、事実上、間違いなく署名スキームであって、電子バンキングのために広く用いられている。

従って、WYSIWYSは、対称暗号技術と改竄防止ハードウェアとの組み合わせを用いて達成され得る。しかし、公開鍵技術に基づく署名スキームは、やり取りが多数対1者、即ち銀行に対してである電子バンキングに対して、多くの独立のパーティが他の独立のパーティとやり取りする電子商取引において重要でない場合、特に有用である。更に、上述の技術や方法のどれも、加入国を通じて採用され、多くの世界各国で参考とされた電子署名に関する欧州議会指令(Directive 1999/93/EC)で規定されたように、ローカルまたはセントラルの(安全な)署名生成デバイスによって実行される法的拘束力のある電子署名に拘束された強いWYSIWYS機能性を提供する要求には対応していない。

対照的に、本発明の主な寄与は、現在は、スマートホン、タブレットPC、および、同様なデバイスを含む、利用可能な最新の技術を用いて、このWYSIWYS機能性を如何に生成するかである。

概要

ユーザのための署名を生成するための方法とシステムが記載される。システムは、署名サーバと、ユーザのための初期処理デバイスと、ユーザのための有効性検証デバイスとを備える。初期処理デバイスは、第1のメッセージMを表示し、前記第1のメッセージMのための署名を生成するよう署名サーバに要求を送るよう構成される。署名サーバは、前記第1のメッセージMに基づいた第2のメッセージM’と、前記ユーザと前記署名サーバとの間で共有される第1の秘密とを用いて有効性検証チャレンジを生成し、前記有効性検証チャレンジを有効性検証デバイスに送るよう構成される。有効性検証デバイスは、前記第1の共有された秘密を用いて前記第2のメッセージM’を再生成し、前記第2のメッセージM’を表示し、表示された第2のメッセージM’が前記第1のメッセージMに対応することのユーザ確認を受け、署名を生成するために要求を確認する有効性検証コードを生成し、前記有効性検証コードを前記署名サーバに送るよう構成される。その後、署名サーバは、第1のメッセージMについてユーザのための署名を生成する。

目的

ゴールは、ドキュメントや取引がユーザによってデジタル的に署名され、基礎をなすインフラ全体が、取引が電子化される前の数世紀の伝統的に受け入れられていたものの特性のほとんどを有する安全な法的フレームワークを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

第1のユーザデバイスと第2のユーザデバイスとを有するユーザのために署名を生成する方法であって、第1のメッセージMのための署名を生成するために、前記第1のユーザデバイスから要求を受けることと、前記第1のメッセージMに基づいた第2のメッセージM’と、前記ユーザと共有された第1の秘密とを用いて有効性検証チャレンジを生成することと、前記第2のユーザデバイスが前記第2のメッセージM’を再生成することを可能にするために、前記有効性検証チャレンジを前記ユーザに送ることと、前記第2のユーザデバイスから有効性検証コードを受けることと、前記有効性検証コードは、署名を生成するための前記要求を確証する、前記第1のメッセージMについて、前記ユーザのために前記署名を生成することと、を備える方法。

請求項2

前記第2のメッセージM’は、前記第1のメッセージと同じである、請求項1に記載の方法。

請求項3

前記有効性検証チャレンジは、前記共有された第1の秘密を用いて前記第2のメッセージM’を暗号化することによって生成される、請求項1または2に記載の方法。

請求項4

前記第2のユーザデバイスによって読むことが可能なバーコードとして前記有効性検証チャレンジを再フォーマットすることと、再フォーマットされた有効性検証チャレンジを前記ユーザに送ることと、を更に備えた、請求項1乃至3のいずれか一項に記載の方法。

請求項5

前記署名を生成する前に前記有効性検証コードを検証することを備える、請求項1乃至4のいずれか一項に記載の方法。

請求項6

前記有効性検証コードは、第2の共有された秘密を用いて検証される、請求項5に記載の方法。

請求項7

前記第2の共有された秘密は、前記共有された第1の秘密とは異なる、請求項6に記載の方法。

請求項8

前記共有された第1の秘密および/または第2の共有された秘密を得るために、前記第2のユーザデバイスにあらかじめ登録することを更に備える、請求項1乃至7のいずれか一項に記載の方法。

請求項9

署名生成デバイスからの第1のメッセージMのための署名の要求を有効性検証する方法であって、前記署名生成デバイスから有効性検証チャレンジを受けることと、前記有効性検証チャレンジは、前記第1のメッセージMに基づく第2のメッセージM’と、前記署名生成デバイスとユーザとの間で共有される第1の秘密とを用いて生成されている、前記共有された第1の秘密を用いて前記有効性検証チャレンジから前記第2のメッセージM’を生成することと、前記ユーザに前記第2のメッセージM’を表示することと、表示されている前記第2のメッセージM’が前記第1のメッセージMと対応していることの確証を受けることと、前記署名を生成するための前記要求を確証する有効性検証コードを生成することと、前記有効性検証コードを出力することと、を備える方法。

請求項10

前記第2のメッセージM’は、前記第1のメッセージMと同じである、請求項9に記載の方法。

請求項11

前記第2のメッセージM’は、前記共有される第1の秘密を用いて前記有効性検証チャレンジを解読することによって生成される、請求項9または10に記載の方法。

請求項12

前記署名生成デバイスと共有された第2の秘密を用いて前記有効性検証コードを生成することを備える、請求項9乃至11のいずれか一項に記載の方法。

請求項13

対称鍵である前記第2の秘密での暗号化を用いて前記有効性検証コードを生成することを備える、請求項12に記載の方法。

請求項14

認証および有効性検証デバイスから前記有効性検証チャレンジを受けることを備える、請求項9乃至13のいずれか一項に記載の方法。

請求項15

前記有効性検証コードを前記認証および有効性検証デバイスに出力することを備える、請求項14に記載の方法。

請求項16

署名生成デバイスから前記有効性検証チャレンジを受けることを備える、請求項9乃至13のいずれか一項に記載の方法。

請求項17

ユーザのために署名を生成する方法であって、第1のユーザデバイスの上に第1のメッセージMを表示することと、前記第1のメッセージMのための署名を生成するために、前記第1のユーザデバイスから署名サーバに要求を送ることと、第1のメッセージMに基づく第2のメッセージM’を生成することと、前記第2のメッセージM’と、前記ユーザと前記署名サーバとの間で共有される第1の秘密とを用いて、有効性検証チャレンジを生成することと、第2のユーザデバイスに前記有効性検証チャレンジを送ることと、前記共有される第1の秘密を用いて、前記第2のユーザデバイスの上で前記第2のメッセージM’を再生成することと、前記第2のユーザデバイスの上に前記第2のメッセージM’を表示することと、前記表示された第2のメッセージM’が前記第1のメッセージMに対応することのユーザ確証を受けることと、署名を生成するための前記要求を確証する有効性検証コードを生成することと、前記第2のユーザデバイスから前記署名サーバに、前記有効性検証コードを送ることと、前記第1のメッセージMのために前記ユーザのための前記署名を生成することと、を備える方法。

請求項18

前記署名を生成する前に、前記有効性検証コードを検証することを更に備える、請求項17に記載の方法。

請求項19

プロセッサ上で実行するときに、請求項1乃至18のいずれか一項に記載の方法を実装するためのプロセッサ制御コード運ぶキャリア

請求項20

ユーザのために署名を生成するための署名サーバであって、前記ユーザは、第1のユーザデバイスと第2のユーザデバイスとを有し、前記署名サーバは、第1のメッセージMのための署名を生成するために、前記第1のユーザデバイスから要求を受けることと、前記第1のメッセージMに基づいた第2のメッセージM’と、前記ユーザと共有される第1の秘密とを用いて有効性検証チャレンジを生成することと、前記第2のユーザデバイスが第2のメッセージM’を再生成できるように、前記有効性検証チャレンジを前記ユーザに送ることと、前記第2のユーザデバイスから有効性検証コードを受けることと、前記有効性検証コードは、署名を生成するための前記要求を確証する、前記第1のメッセージMのために前記ユーザのための署名を生成することと、から構成される、署名サーバ。

請求項21

前記ユーザのための署名を生成するために署名生成デバイスを備える、請求項20に記載の署名サーバ。

請求項22

前記署名生成デバイスは、ユーザにローカルである、請求項21に記載の署名サーバ。

請求項23

前記署名生成デバイスは、有効性検証チャレンジを生成する、請求項21または22のいずれか一項記載の署名サーバ。

請求項24

前記署名生成デバイスと前記第2のユーザデバイスの両方は、前記共有される第1の秘密を記憶する、請求項23に記載の署名サーバ。

請求項25

前記有効性検証チャレンジを生成するために認証および有効性検証サーバを備える、請求項20乃至22のいずれか一項に記載の署名サーバ。

請求項26

前記認証および有効性検証サーバと前記第2のユーザデバイスの両方は、前記共有される第1の秘密を記憶する、請求項25に記載の署名サーバ。

請求項27

前記認証および有効性検証サーバは、ユーザから離れている請求項25または26のいずれか一項に記載の署名サーバ。

請求項28

第1のメッセージMのための署名の要求を有効性検証するためのユーザのための有効性検証デバイスであって、署名生成デバイスから有効性検証チャレンジを受けることと、前記有効性検証チャレンジは、前記第1のメッセージMに基づく第2のメッセージM’と、前記署名生成デバイスと前記有効性検証デバイスとの間で共有される第1の秘密とを用いて生成されている、前記共有される第1の秘密を用いて前記有効性検証チャレンジから前記第2のメッセージM’を生成することと、前記ユーザに前記第2のメッセージM’を表示することと、前記第2のメッセージM’が前記第1のメッセージMに対応することのユーザ確証を受けることと、前記署名を生成するために前記要求を確証する有効性検証コードを生成することと、前記有効性検証コードを出力することと、から構成される有効性検証デバイス。

請求項29

前記第2のメッセージM’は、前記第1のメッセージMと同じである、請求項28に記載の有効性検証デバイス。

請求項30

前記第2のメッセージM’は、前記共有される第1の秘密を用いて前記有効性検証チャレンジを解読することによって生成される、請求項28または29のいずれか一項に記載の有効性検証デバイス。

請求項31

前記有効性検証デバイスは、前記署名生成デバイスと共有され、前記有効性検証デバイスの上に記憶された第2の秘密を用いて前記有効性検証コードを生成するよう構成される、請求項28乃至30のいずれか一項に記載の有効性検証デバイス。

請求項32

前記有効性検証デバイスは、対称鍵である前記第2の秘密での暗号化方法を用いて前記有効性検証コードを生成するよう構成される、請求項31に記載の有効性検証デバイス。

請求項33

前記有効性検証デバイスは、認証および有効性検証デバイスから前記有効性検証チャレンジを受けるよう構成される、請求項28乃至32のいずれか一項に記載の有効性検証デバイス。

請求項34

前記有効性検証デバイスは、前記有効性検証コードを前記認証および有効性検証デバイスに出力するよう構成される、請求項33に記載の有効性検証デバイス。

請求項35

前記有効性検証デバイスは、署名生成デバイスから前記有効性検証チャレンジを受けるよう構成される、請求項28乃至34のいずれか一項に記載の有効性検証デバイス。

請求項36

請求項20乃至27のいずれか一項に記載の署名サーバと、請求項28乃至35のいずれか一項に記載の有効性検証デバイスとを備える、ユーザのための署名生成システム

請求項37

署名サーバ、ユーザのための初期処理デバイス、および、ユーザのための有効性検証デバイスを備えたシステムであって、前記初期処理デバイスは、第1のメッセージMを表示することと、前記第1のメッセージMのための署名を生成するために前記署名サーバに要求を送ることと、をするよう構成され、前記署名サーバは、前記第1のメッセージMに基づく第2のメッセージM’と、前記ユーザと前記署名サーバとの間で共有される第1の秘密とを用いて有効性検証チャレンジを生成することと、前記有効性検証デバイスに前記有効性検証チャレンジを送ることと、をするように構成され、前記有効性検証デバイスは、前記共有される第1の秘密を用いて前記第2のメッセージM’を再生成することと、前記第2のメッセージM’を表示することと、前記表示された第2のメッセージMが前記第1のメッセージMに対応することのユーザ確証を受けることと、署名を生成するための前記要求を確証する有効性検証コードを生成することと、前記有効性検証コードを前記署名サーバに送ることと、をするように構成され、前記署名サーバは、前記第1のメッセージMのために前記ユーザのための署名を生成する、システム。

技術分野

0001

本発明は、デジタル署名を要求し、提供するための方法と装置に関する。

背景技術

0002

デジタル署名の概念がもたらされてから40年近くがたっても、依然、電子商取引(e-commerce)として知られるものにおいて、いくつもの課題が存在する。ゴールは、ドキュメント取引がユーザによってデジタル的に署名され、基礎をなすインフラ全体が、取引が電子化される前の数世紀の伝統的に受け入れられていたものの特性のほとんどを有する安全な法的フレームワークを提供するような仕組みである。
簡潔に言えば、主な課題は、以下のシステムを提供することである:
1)"What You See Is What You Sign"(あなたが見るものがあなたがサインするもの)または"WYIWYS"として知られているキャッチフレーズにおけるものを提供し、以下のような方法で、ユーザが"what he sees"(彼が見たもの)にサインしようと決めることを可能にする:
2)特定の取引またはドキュメント上のこの特定のデジタル署名が、特定のユニークに識別されたユーザの意思による行為で生成されたことの実体的で説得力のある証拠(特に、法的な意味で)を与えることが可能である。

0003

"WYSIWYS"の概念は、Peter LandrockとTorben Pedersenによる「“WYSIWYS? What you see is what you sign?” Information Security Technical Report, Elsevier, Vol 3, No 2, 1998」に紹介された。

0004

他の基本的な技術論文は、Fiat Shamirの「“How to Prove Yourself: Practical Solutions to Identification and Signature Problems” Advances in Cryptology, CRYPTO’86 Proceedings, Lecture Notes in Computer Science, Springer Verlag 1986」である。この論文は、電子データの確実な搬送に関連する以下の様々なスキームを定義している。
認証(authentication)スキーム:Aは、Bに対し、彼がAであることを証明できるが、他の誰も、Bに対し、彼がAであることを証明できない。
証明(identification)スキーム:Aは、Bに対し、彼がAであることを証明できるが、Bは、他の誰かに対し、彼がAであることを証明できない。
署名(signature)スキーム:Aは、Bに対し、彼がAであることを証明することができるが、Bは、彼自身にさえ、彼がAであることを証明できない。

0005

認証スキームは、共有鍵を用いた対称暗号化技術を用いることによって可能である。ソフトウェアベースプロトコルにおいて、より強力な証明スキームは公開鍵技術を必要とした。これらの技術は、Aの秘密鍵が含まれたが、それは、彼の鍵が選ばれたコンテンツをもったメッセージに適用されることを必要としないことを証明する。いわゆるゼロ知識証明スキーム(zero-knowledge identification scheme)がこのカテゴリーにはいる。最後に、安全な署名スキームにおいて、これが可能である証明スキームとは反対に、基礎をなすプロトコルはBによってシミュレートされることができない。

0006

署名スキームのための1つのコンセプトは、各ユーザが、マイクロチップを主とするスマートカードまたは署名スティック等のローカル署名生成デバイス上に記憶された彼の秘密鍵を持って回ることであった。このアプローチは、それがUSBポートおよび/またはスマートカードリーダー利用可能性、webベース環境におけるそのような周辺機器を使用することの不十分な適応可能性、および、古いデバイスと現代のデバイス、または、異なるブランドを有するデバイスの間の可能な互換性の問題を必要とするので、いくつかの重大な欠点を有する。また、ユーザが、可動性と使用の容易さの障害となる安全な場所に署名生成デバイスを保管することが不可欠である。このアプローチは、現実に、全国的規模の開発や高い利用率をもっていきわたらず、派生した開発は、少ないユーザをもった管理された環境に制限されている。

0007

署名スキームのための代わりのアプローチは、欧州特許1364508に記載されている。このスキームは、秘密鍵の所有者が秘密鍵に対する唯一コントロールを保持することを保証するが、ユーザのための署名の生成のための秘密鍵を中央で記憶するセントラル(安全な)署名生成デバイスを用いる。このアプローチは、現在、例えば、デンマークノルウェイ、ルクセンブルグにおいて、ほとんど全ての市民ビジネス、および、公的サービス機関によって広く使用されている。

0008

過去30年の間に、いくつかの他の商業的な解決策が発展し、アタックがますます精巧になってくるにつれて、ますます進歩している。安全性の低い解決策は、ユーザのみを特定しようとするがメッセージ自身の安全を守らない、ある程度のセッションセキュリティを与える解決策である。例えば、1つの初期の解決策は、メッセージとともに転送される静的なパスワードに依存し、最近の解決策は、メッセージとともに転送されるためのいわゆるOTP(One Time Password)(しかし、依然、メッセージの内容とは独立に生成される)に依存している。

0009

スマートホン到来でもって、新たな機会の領域が出願した。これらは、例えば、欧州特許第1969880および欧州特許第1959374において利用されており、専用のハードウェアを用いて、実際に、認証と証明に関する上記2つの要件合致するが、かなり高価なハードウェアの使用を代償としている。

0010

しかし、これらのアプローチのどれも、WYSIWYSの特性−声の確認または個別チャネルの使用等の更なる手段なくその目的にかなうことが重要である−を保証しない。

0011

WYSIWYSの1つの強力な実現は、最もユーザフレンドリーではないにもかかわらず、Mastercardによって開発され、後にDPA(Dynamic Passcode Authentication)としてVisaによって採用された、CAP(Chip Authentication Program)であり、それは、スタンドアロンカードリーダーと、デビットまたはクレジットEMチップカードを必要とする。ユーザが、例えばワークステーション上で支払の明細を与えたら、彼は、かれのPINをキー入力し、「署名(Sign)」機能を選択することによって、かれのデビットカードまたはクレジットカードをカードリーダーに入れることを求められる。かれは、次に、支払われるべき額と受取人口座をキー入力することを要求され、メッセージ認証コード(message authorization code:MAC)が彼のデビットまたはクレジットカードによって生成され、カードリーダーに表示される。続いて、彼は、ワークステーション上での彼の取引とともにこれをキー入力する。

0012

この背景にある暗号法は、支払カードバンクバックエンドとの間で共有される鍵をもちいた対称暗号化システムである。そして、これは、上述の定義でもって、「認証スキーム」であるように見える。しかし、支払カードとバンクバックエンド上の鍵が改竄防止ハードウェアによって保護されているので、これは、事実上、間違いなく署名スキームであって、電子バンキングのために広く用いられている。

0013

従って、WYSIWYSは、対称暗号技術と改竄防止ハードウェアとの組み合わせを用いて達成され得る。しかし、公開鍵技術に基づく署名スキームは、やり取りが多数対1者、即ち銀行に対してである電子バンキングに対して、多くの独立のパーティが他の独立のパーティとやり取りする電子商取引において重要でない場合、特に有用である。更に、上述の技術や方法のどれも、加入国を通じて採用され、多くの世界各国で参考とされた電子署名に関する欧州議会指令(Directive 1999/93/EC)で規定されたように、ローカルまたはセントラルの(安全な)署名生成デバイスによって実行される法的拘束力のある電子署名に拘束された強いWYSIWYS機能性を提供する要求には対応していない。

0014

対照的に、本発明の主な寄与は、現在は、スマートホン、タブレットPC、および、同様なデバイスを含む、利用可能な最新の技術を用いて、このWYSIWYS機能性を如何に生成するかである。

0015

本発明の第1の態様に従って、第1と第2のユーザデバイスを有するユーザのための署名を生成する生成する方法が提供され、
方法は
第1のメッセージMのための署名を生成するために、前記第1のユーザデバイスから要求を受けることと、
前記第1のメッセージMに基づいた第2のメッセージM’と、前記ユーザと共有された第1の秘密を用いて有効性検証チャレンジとを生成することと、
前記第2のユーザデバイスが前記第2のメッセージM’を再生成することを可能にするために、前記有効性検証チャレンジを前記ユーザに送ることと、
前記第2のユーザデバイスから有効性検証コードを受けることと、前記有効性検証コードは、署名を生成するための前記要求を確証することと、
前記第1のメッセージMについて、前記ユーザのために前記署名を生成することと、
を備える。

0016

本発明の第2の態様に従って、第1と第2のユーザデバイスを有するユーザのために署名を生成するための署名サーバが提供され、
サーバは、
第1のメッセージMのための署名を生成するために、前記第1のユーザデバイスから要求を受けることと、
第1のメッセージMに基づいた第2のメッセージM’と、前記ユーザと共有された第1の秘密とを用いて有効性検証チャレンジを生成することと、
前記第2のユーザデバイスが前記第2のメッセージM’を再生成することを可能にするために、前記ユーザに前記有効性検証チャレンジを送ることと、
前記第2のユーザデバイスから有効性検証コードを受けることと、前記有効性検証コードは署名を生成するための要求を確証する、
第1のメッセージMのためにユーザのための署名を生成することと、
から構成される。

0017

従って、本発明の主要な特徴は、好ましくはお互いに別個である第1と第2のユーザデバイスとの相互作用である。署名のための要求は第1のユーザデバイスから受け取られ、署名が生成される前に第2のユーザデバイスから確証される。更に、署名要求を確証する前に、ユーザがメッセージを見ることができるために、メッセージが第2のユーザデバイス上で再生成できるよう、有効性検証チャレンジが生成される。従って、“What You See Is What You Sign” (WYSIWYS)の機能性が提供される。

0018

方法は、署名サーバの中のプロセッサ上で実行される生成ステップと、署名サーバの入力/出力システムによって実行される受け取り送りのステップとを有するコンピュータ実装された方法である。

0019

署名サーバは、署名生成デバイス、例えば、電子署名についての欧州議会指令(Directive 1999/93/EC)によって定義されているような安全な署名生成デバイスを備える。署名生成デバイス(より具体的には、署名生成デバイスのプロセッサ)は、署名を生成するための要求を受け、最終的に署名を生成する。署名は、好ましくは、先進の電子署名、即ち、署名者一意的にリンクされた署名であり、署名者を特定することができ、署名者が彼の唯一の制御のもとに維持できる手段を用いて生成され、データの以降の変更が検出可能であるような方法で署名が関係するデータにリンクされる。

0020

署名サーバは、ローカルであってもよく、または、ユーザから離れていてもよい。ローカルによれば、署名生成デバイスは、ユーザによって所有(即ち、保有)される。離れている場合、署名生成デバイスは、ユーザから物理的に分離されており、例えば、別個のエンティティによって管理され得るセントラル署名サーバ上にある。

0021

署名生成デバイスは、また、有効性検証チャレンジを生成し、したがって、単一のエンティティが有効性検証チャレンジと署名との両方を提供する。しかし、2つのユーザデバイスとの相互作用は、依然、セキュリティを確実にするために必要とされる。この構成において、署名生成デバイスは、ユーザにローカルであり得る。

0022

署名サーバは、個別の認証および有効性検証サーバを備え得る。認証および有効性検証サーバ(より具体的には、認証および有効性検証サーバのプロセッサ)は、有効性検証チャレンジを生成し得る。認証および有効性検証サーバは、署名生成デバイスから離れているまたは一体になって入れもよい。

0023

第1の共有された秘密は、それに応じて有効性検証チャレンジを生成している認証および有効性検証サーバ、または、署名生成デバイス上に記憶され得る。従って、ユーザは、第1の共有された秘密の共有を可能にするために、第2のユーザデバイスを、署名サーバ(より具体的には、署名生成デバイス、または、有効性検証チャレンジ生成する認証および有効性検証サーバ)に登録することが必要である。

0024

有効性検証チャレンジは、派生された第1のメッセージである第2のメッセージM’に基づいており、従って、有効性検証チャレンジはオリジナルメッセージから派生される。従って、ユーザが有効性検証チャレンジからメッセージM’(または、可能ならばオリジナルメッセージM)を再生成できるならば、ユーザはこの有効性検証者レンジ信頼されているソースから来ることを保証され得る。更に、ユーザは、署名生成プロセスの部分として有効性検証のためにユーザに提示される前に、メッセージが変更されていないことを再保証されることができる。従って、ユーザは、メッセージに署名する要求を確証できる。これは"WYSIWYS"機能性を提供する。

0025

第2のメッセージM’は、第1のメッセージMと同一であり得、または、第1のメッセージMから得られ得る。M’は、ハンドヘルドデバイス上に表示されるように設計される。第2のメッセージM’は、有効性検証の目的のためにユーザへの表示を単純化するために、第1のメッセージMの簡略表記されたバージョンであり得る。代替的に、第2のメッセージM’は第1のメッセージの異なるバージョンであってもよい。第2のメッセージM’がユーザに表示されるとき、第2のメッセージM’が、かれが署名されるべきであると望む第1のメッセージMに関係することをユーザが確証することができるように、第2のメッセージM’は、好ましくは、第1のメッセージからの十分な情報を備える。Mは、例えば、購入オーダーであってよく、M’は、例えば、POリファレンス受領者、額をもったそのサマリーである。第2のメッセージM’は、署名生成デバイスによって生成され得、または、第1のユーザデバイスによって生成され得る。それがどこで生成されるかにかかわらず、M’は、最終的に、有効性検証チャレンジを生成するために署名サーバによって受け取られる。

0026

有効性検証チャレンジは、好ましくは、前記第2のメッセージM’が前記第1の共有された秘密を用いて前記有効性検証チャレンジから得られることが可能であるように生成される。例えば、前記有効性検証チャレンジは、前記第1の共有された秘密を用いて前記有効性検証チャレンジを解読することが前記第2のメッセージM’を再生成するように、前記第1の共有された秘密を用いて前記第2のメッセージM’を暗号化することによって、対称暗号化により生成され得る。代替的に、有効性検証チャレンジは、メッセージ認証コード(message authentication code:MAC)の形式で、第1の共有された秘密を用いて生成され得る。代替的に、有効性検証チャレンジは、ユーザに関連付けられた秘密鍵の形式で第1の共有された秘密、第2のユーザデバイスに存在する秘密鍵の公開部分、を用いて署名されたM’のデジタル的に署名されたバージョンであり得る。従って、第1の共有された秘密を交換する、または、さもなければ同意するために、デバイスを事前登録することが必要である。

0027

有効性検証チャレンジは、直接または間接に第2のユーザデバイスに送られ得、例えば、有効性検証チャレンジは第1のユーザデバイスを介して送られ得る。方法は、更に、第2のユーザデバイスによって読むことが可能なバーコード(例えば、QRコード(登録商標))として有効性検証チャレンジを再フォーマットすることを備える。バーコードは、第2のユーザデバイスによって読まれるために、第1のユーザデバイス上に表示され得る。

0028

有効性検証コードは、第2のユーザデバイスから直接または間接に受け取られ得る。有効性検証コードは、署名が生成される前に検証され得る。検証は、有効性検証コードが第2のユーザデバイスから受け取られていることをチェックする。検証は、任意の標準のプロセスによって行われ得る。従って、有効性検証コードは、ユーザに特有な、好ましくは、有効性検証チャレンジを生成するために用いられた情報とは異なる情報、即ち、第2の共有された秘密を用いて生成されなければならない。

0029

署名を生成する前に、署名サーバは、有効性検証コードがユーザからのものであることを検証することが必要である。有効性検証コードの検証は、−それが用いられる場合—、認証および有効性検証サーバによって実行され得、検証の結果は、署名生成デバイスに送られ得る。この場合、署名生成デバイスは、また、結果が認証および有効性検証サーバからのものであることを検証し得る。代替的に、有効性検証コードの検証は、署名生成デバイス自身によって行われてもよい。第2の共有された秘密が有効性検証コードを生成するために用いられるならば、これは、また、有効性検証コードを検証するデバイスに記憶される。従って、デバイスの事前登録の一部として第2の共有された秘密を交換、または、さもなければ同意することが必要である。

0030

ユーザは、少なくとも2つのデバイス、第1のユーザデバイスと第2のユーザデバイスを有する。代替的に、ユーザは、第1と第2のユーザデバイスの機能性を併合する単一のデバイスを有してもよい。従って、第1のユーザデバイスは、また、第2のユーザデバイスであり得る。この単一のデバイスは、2者の機能性を提供するよう適用されなければならず、例えば、単一のデバイスが2つの独立のチャネルを扱うことができる、および/または、信用のおけるグラフィカルユーザインタフェースを有し得る。第1のユーザデバイスは、署名のための要求を送出する。第2のユーザデバイスは、有効性検証チャレンジから第2のメッセージM’を再生成し、署名を生成するための要求を確証する有効性検証コードを生成する。第1のユーザデバイスは初期処理デバイスと呼ばれ得、第2のユーザデバイスは有効性検証デバイスと呼ばれ得、これらの用語は明細書を通じて互換的に用いられる。初期処理デバイスは、ワークステーション、ラップトップコンピュータ、タブレット、または、スマートホン等の任意の電子デバイスであり得る。同様に、有効性検証デバイスは、任意の電子デバイスであってよいが、好ましくは、初期処理デバイスに対して異なる電子デバイスである。

0031

発明の他の態様に従って、ユーザが第1のメッセージMのための署名要求を有効性検証するための有効性検証デバイスが提供され、
有効性検証デバイスは、
署名生成デバイスから有効性検証チャレンジを受けることと、有効性検証チャレンジは、第1のメッセージMに基づく第2のメッセージM’と、署名生成デバイスと有効性検証デバイスとの間で共有される第1の秘密とを用いて生成されている、
第1の共有された秘密を用いて有効性検証チャレンジから第2のメッセージM’を生成することと、
第2のメッセージM’をユーザに表示することと、
第2のメッセージM’が第1のメッセージMに対応することのユーザ確証を受け取ることと、
署名を生成するための要求を確証する有効性検証コードを生成することと、
有効性検証コードを出力することと、
から構成される。

0032

発明の他の態様に従って、署名生成デバイスから第1のメッセージMのための署名要求をする方法が提供され、
方法は、
署名生成デバイスから有効性検証チャレンジを受けることと、有効性検証チャレンジは、第1のメッセージMに基づく第2のメッセージM’と、前記署名生成デバイスと前記ユーザとの間で共有される第1の秘密とを用いて生成されている、
第1の共有された秘密を用いて、有効性検証チャレンジから第2のメッセージM’を生成することと、
ユーザに、第2のメッセージM’を表示することと、
第2のメッセージM’が第1のメッセージMに対応することの確証を受け取ることと、
署名を生成するための要求を確証する有効性検証コードを生成することと、
有効性検証コードを出力することと、
を備える。

0033

本発明の第1と第2の態様に関連して上述された特徴は、ユーザによって利用されるデバイスやステップに関係する本発明のこれらの態様にも適用される。例えば、有効性検証チャレンジと第2のメッセージM’は、上述のように生成され、送られ得る。

0034

第2のメッセージM’は、解読によって有効性検証チャレンジから生成され得る。例えば、第1の共有された秘密は、対称鍵であってよい。代替的に、有効性検証チェレンジは、有効性検証チャレンジから得られるメッセージ認証コード(message authentication code:MAC)を検証することによって第1の共有された秘密を用いて有効性検証され得る。

0035

代替的に、第1の共有された秘密は、ユーザに関連付けられた秘密鍵であってもよく、秘密鍵の公開部分が第2のユーザデバイスに存在する。この場合には、第2のメッセージM’は、有効性検証チャレンジに秘密鍵の公開部分を適用することによって生成される。

0036

有効性検証コードは、ユーザに固有であり、好ましくは、有効性検証チャレンジを生成するために用いられる情報、例えば、第2の共有された秘密、とは異なる情報、を用いて生成されなければならない。有効性検証コードは、OATHチャレンジレスポンスアルゴリズム(OATH challenge response algorithm:OCRA)[RFC 6287- ISSN 2070-1721に記載される)、または、MastercardCAP、Visa CodeSure、Vasco Digipass challenge response based mechanisms等の等価な独占技術を含む種々の規格化された方法を用いて生成され得る。有効性検証コードは、有効性検証デバイスとセントラル認証および有効性検証サーバまたは署名生成デバイス(どのデバイスが有効性検証コードを検証しているかによって)との間で共有される対称鍵である第2の秘密での暗号化を用いて生成され得る。有効性検証コードは、また、リプレイアタックを避けるために、ノンスを用いた署名された応答であり得る。

0037

上述のように、署名サーバは、署名生成デバイスおよび/または認証および有効性検証デバイスを備える。認証および有効性検証デバイスがある場合、有効性検証デバイスは、認証および有効性検証デバイスから有効性検証チャレンジを受け得、認証および有効性検証デバイスに有効性検証コードを出力し得る。この場合において、必要な秘密が共有されることを保証するために、有効性検証デバイスを、認証および有効性検証デバイスに予め登録する必要がある。代替的に、認証が署名生成デバイス自身によって行われる場合には、有効性検証デバイスは、署名生成デバイスから有効性検証チャレンジを受け取り得、有効性検証コードを署名生成デバイスに出力し得る。

0038

本発明のためのフルシステムは、署名サーバ、第1のユーザデバイス(初期処理デバイス)、および、第2のユーザデバイス(有効性検証デバイス)を備える。本発明の他の態様に従うと、メッセージMのための署名を与えるためのシステムが提供され、このシステムは、上述の署名サーバ、上述の第1のユーザデバイス、および、上述の第2のユーザデバイスを備える。

0039

本発明の他の態様に従えば、署名サーバ、ユーザのための初期処理デバイス、および、ユーザのための有効性検証デバイスを備えるシステムが提供され、
初期処理デバイスは、
第1のメッセージMを表示することと、
前記第1のメッセージのための署名を生成するために、署名サーバに要求を送ることと、
のために構成され、
署名サーバは、
前記第1のメッセージMに基づく第2のメッセージM’と、前記ユーザと前記署名サーバとの間で共有された第1の秘密とを用いて有効性検証チャレンジを生成することと、
前記有効性検証チャレンジを有効性検証デバイスに送ることと、
のために構成され、
有効性検証デバイスは、
前記第1の共有された秘密を用いて前記第2のメッセージM’を再生成することと、
前記第2のメッセージM’を表示することと、
表示された第2のメッセージM’が第1のメッセージMに対応することのユーザ確証を受けることと、
署名を生成するための要求を確証する有効性検証コードを生成することと、
前記署名サーバに前記有効性検証コードを送ることと、
のために構成され、
それによって、前記署名サーバは、第1のメッセージMのためにユーザのための署名を生成する。

0040

同様に、本発明の他の態様に従って、
第1のユーザデバイス上に第1のメッセージMを表示することと、
前記第1のンメッセージMのための署名を生成するために、前記第1のユーザデバイスから署名サーバに要求を送ることと、
第1のメッセージMに基づいた第2のメッセージM’を生成することと、
前記第2のメッセージM’と、前記ユーザと前記署名サーバとの間で共有された第1の秘密とを用いて、有効性検証チャレンジを生成することと、
第2のユーザデバイスに前記有効性検証チャレンジを送ることと、
前記第1の共有された秘密を用いて、前記第2のユーザデバイス上で前記第2のメッセージM’を再生成することと、
前記第2のメッセージM’を前記第2のユーザデバイス上に表示することと、
第2のメッセージM’が前記第1のメッセージMに対応することのユーザ確証を受けることと、
署名を生成するための要求を確証する有効性検証コードを生成することと、
前記第2のユーザデバイスから前記署名サーバに前記有効性検証コードを送ることと、
第1のメッセージMのためにユーザのための署名を生成することと、
を備える方法が提供される。

0041

本発明は、更に、上述のシステムと方法を、例えば汎用コンピュータシステム上に、または、デジタル信号プロセッサ(digital signal processor:DSP)上に実装するためのプロセッサ制御コードを提供する。コードは、ディスクCD−ROM、DVD−ROM,不揮発性メモリ(例えば、フラッシュ)またはリードオンリーメモリファームウェア)等のプログラマブルメモリ等の物理的なデータキャリア上で提供される。本発明の実施形態を実装するためのコード(および/または、データ)は、Cまたはアセンブリコード等の従来のプログラミング言語インタープリットされるか、または、コンパイルされる)でのソース、オブジェクト、または、実行可能コードを備え得る。技術に習熟した者が理解するように、そのようなコードおよび/またはデータは、お互いにやり取りしあう、複数の結合されたコンポーネントの間で分散され得る。

0042

本発明は、以下の添付の図面において、例として図示される。

図面の簡単な説明

0043

図1aは、システムにおける種々のデバイスによって使用されるステップのフローチャートである。
図1bは、サンプルメッセージである。
図2aは、システムを通じた情報の流れを示す、システムの一構成についての概略図である。
図2bは、図2aに示された実装例についてのフローチャートである。
図2cは、図2aに示された実装例についてのフローチャートである。
図3aは、システムの他の構成についての概略システム図である。
図3bは、図3aに示された実装例についてのフローチャートである。
図3cは、図3aに示された実装例についてのフローチャートである。
図4aは、システムの他の構成についての概略システム図である。
図4bは、図4aに示された実装例についてのフローチャートである。
図4cは、図4aに示された実装例についてのフローチャートである。
図5aは、ユーザデバイスのコンポーネントを示す概略ブロック図である。
図5bは、セントラル認証および有効性検証サーバ、または、署名生成デバイスのコンポーネントを示す概略ブロック図である。

詳細な説明

0044

図1aは、この新規な発明が、複数のデバイスを用いた強い"WYSIWYS"機能性を如何にして提供するかを示すフローチャートである。システムは、3つのキーデバイスを備える;署名生成デバイス(signature creation device:SCD)と、初期処理デバイス(initial transaction device)と有効性検証デバイス(validation device)とここでは呼ばれるユーザによって保持される好ましくは2つのデバイスである。図2aから図4aを参照してより詳細に説明されるように、署名生成デバイスは、実際のデジタル署名生成が実行される場所である。署名生成デバイスは、署名サーバ等のセントラルSCD、または、スマートカードまたは署名スティックの等のローカル署名生成デバイスであり得る。初期処理デバイスは、ワークステーション、ラップトップコンピュータ、タブレットまたはスマートホン等の任意の電子デバイスであり得る。同様に、有効性検証デバイスは、任意の電子デバイスであってよいが、好ましくは、初期処理デバイスに対して異なる電子デバイスである。2つの独立の通信チャネルがあり、メッセージが即時の検出なしに変更されることを避けるために、セキュリティの適切なレベルでもって"WYSIWYS"を達成するため、初期処理デバイスと有効性検証デバイスの各々に1つである。ただ1つのユーザデバイスが用いられたとすると、信頼されたGUI(Graphical User Interface)等の追加の改竄防止態様を有しなければならなかったであろう。

0045

始めに、ステップ100において、ユーザは、彼がデジタル署名を用いてコミットするよう準備された特定のメッセージMを特定するために初期処理デバイスを用いる。メッセージは、電子形式の取引、ドキュメント、または、購入オーダーであってよい。購入オーダーの形式でのメッセージの例が図1bに示される。

0046

初期処理デバイスが安全でないプラットホームであり得る場合、初期処理デバイス上での攻撃者がメッセージを他のものと置き換え得るから、ユーザは、一般的に、このデバイス上でメッセージに署名をすることにコミットできない。従って、ユーザがメッセージMを受け入れ(S102)、そのメッセージに署名することを望むとすると、署名生成デバイスに署名生成の要求をする(S104)。

0047

メッセージMに署名するための要求をSCDが受け取ったら(S106)、SCDは、ユーザがこの特定のメッセージに署名することにコミットしていることの証拠を受け取るまで、署名を生成しない。本質的に、これは、有効性検証デバイスにメッセージ(または、その一部)を送ることによって達成される。従って、ステップS108において、メッセージの派生バージョンM’が生成される。M’は、メッセージMの全体であってもよく、または、メッセージM内の情報の抽出から生成されてもよい。従って、図1bの例では、ハイライトされたフィールド11がM’を形成するために用いられ得る。

0048

M’は、署名生成デバイスによって生成されるとして図1aに示されるが、それは、以下に図2b、3b、および4bに示されたように、システム内の処理デバイスまたは他のデバイスによって生成されることができる。それは、有効性検証チャレンジの生成のために署名生成デバイスで受け取られる必要がある(S110)。以下により詳細に説明されるように、有効性検証チャレンジは、また、メッセージに基づくか、または、メッセージから派生される。

0049

有効性検証チャレンジは、有効性検証デバイスに送られる(S112)。原メッセージから派生される有効性検証チャレンジの生成によって、ユーザは、署名生成プロセスの一部としての有効性検証のためにユーザに提示される前にそれが変えられていないことを信じるために、受け入れ可能な理由をもって信頼されたソースからこの派生されたメッセージが来ることを保証される。有効性検証デバイス(デバイス上で実行する特定のアプリケーションを含み得る)は、メッセージの派生されたバージョンM’を表示する(S114)。ユーザが処理を認識するならば、彼は、有効性検証デバイス上でそれを承認し(S116)、その場合にはユニークな有効性検証コードが生成される(S118)。この有効性検証コードは署名生成デバイスにおいて受け取られ(S120)、処理がセントラルまたはローカルSCD(S122)によって署名される前に検証されなければならない。検証は、この検証が成功した場合、署名のみが生成され得ることを保証する。

0050

イノベーションは、SCDがセントラル署名サーバであるかまたはローカルデバイス(スマートカード、USB、署名スティック)であるかどうかに応じて、いくつかの現実化を可能にする。後者の場合、ユニークな有効性検証コードを検証するための様々な現実化がある。

0051

プロセスは、有効性検証デバイスを登録し、いくつかの対称または非対称の鍵でそれを個人的にするために設定されなければならない。これは、当技術において周知であり、従って詳細には記載されない標準的な技術である。

0052

図2aから図2cは、複数のデバイスを用いて強い"WYSIWYS"機能性を提供するための1つの構成を示す。図2aに示されるように、この構成は、ユーザデバイス:初期処理デバイス10と有効性検証デバイス12、を備える。これらのデバイスは、"WYSIWYS"機能性の部分として、お互いに独立である。構成は、また、ユーザデバイスから離れて設置され、セントラル署名生成デバイス14とセントラル認証および有効性検証デバイス16とを備えるセントラルシステムを備える。セントラル署名生成デバイス14は、初期処理デバイス10に接続され、セントラル認証および有効性検証サーバ16は、有効性検証デバイス12に接続される。従って、ユーザデバイス12、14の各々は、システムの中央部との個別の独立な通信チャネルを有する。

0053

図2aにおいて、署名生成デバイス14とセントラル認証および有効性検証サーバ16は、お互いに、好ましくは安全な接続を介して、接続される2つの個別のエンティティとして示される。これは、単に、各エンティティがプロセスにおいて異なる機能や役割を有することを示すにすぎない。署名生成デバイス14とセントラル認証および有効性検証デバイス16の個々の機能は、また、単一のエンティティ、例えば、単一の署名サーバによって提供され得ることが認識される。

0054

システムまわりの情報の流れは、数字1から8によって示され、図2bと2cに関連してより詳細に説明される。最初に、矢印1によって示されるように、ユーザは、初期処理デバイス上に表示されているメッセージMの内容に同意し、受け入れる(S200)。受け入れることは、彼が、デジタル署名をもったメッセージにコミットする準備がされていることを意味する。前記メッセージMは、オプションとして、アプリケーションプロバイダーによって制御されたリモートwebサーバからwebHTMLページを受け取っている初期処理デバイスのクライアントブラウザ上で提示され得る。

0055

矢印2aによって示されたように、ユーザは、メッセージMまたはそのハッシュされたバージョンのための署名を要求するために、セントラルSCDまたは署名サーバにコンタクトする(S202)。メッセージの派生されたバージョン、M’と呼ばれる、が生成される。M’は、Mと同じであってよく、または、Mから派生されてもよいが、本質的に同じ内容を有する。Mは、例えば、購入オーダーであってよく、M’は、例えば、PO問い合わせ番号、受領者、額等を有したそのサマリーである。ステップ204a、204b、204cによって示されるように、M’は、初期処理デバイス、SCDまたはセントラル認証および有効性検証サーバによって計算処理される。それがどこで生成されるにかかわらず、矢印2bによって示されたように、セントラル認証および有効性検証サーバが最終的にM’を受け取ること(S206)を保証するために、セントラルSCDとセントラル認証および有効性検証サーバとの間のやり取りがある。

0056

矢印3とS208によって示されるように、有効性検証チャレンジVCM’,userが、メッセージM’とM’に関連付けられたユーザ(そして、従って、原メッセージM)のために、セントラル認証および有効性検証サーバによって生成される。この有効性検証チャレンジは、M’の暗号化によって安全が確保された関数であり、任意の既知技法を用いて生成され得る。有効性検証チャレンジは、ユーザとセントラル認証および有効性検証サーバにユニークである情報を用いてメッセージM’を保護する必要があり、それにより、有効性検証チャレンジが原メッセージMに基づき、信頼のおけるソースからのものであることを、ユーザが確かだと思い得る。更に、有効性検証デバイスは、有効性検証チャレンジからM’を回復することができる必要がある。例えば、有効性検証チャレンジは、認証および有効性検証サーバと有効性検証デバイスとの両方によって共有される対称鍵のもとでの暗号化を用いて生成され得る。同様に、有効性検証チャレンジは、認証および有効性検証サーバと有効性検証デバイスの両方によって共有されるメッセージ認証コード(message authentication code:MAC)を用いて生成され得る。代替的に、有効性検証チャレンジは、ユーザに関連付けられた秘密鍵、有効性検証デバイスに存在する秘密鍵の公開部分、を用いて署名されたM’のデジタル署名バージョンであり得る。有効性検証チャレンジの生成は、有効性検証チャレンジが生成されることを可能にするために、初期の段階でユニークな情報(例えば、対称鍵、公開/秘密鍵、または、MAC)を共有するために、有効性検証デバイスが登録されているか、他に、セントラル認証および有効性検証サーバとリンクされていることを必要とすることが認識される。

0057

破線矢印4およびステップ210によって示されるように、有効性検証チャレンジVCM’,userは、有効性検証デバイスに送られる。破線は、有効性検証デバイスとの接続が、例えば、初期処理デバイスを介して間接であり得る、または、以下に記載のように直接であることを示す。更に、有効性検証チャレンジは、送る前に再フォーマットされ得る例えば、規格化されたクイックレスポンス(quick response:QR)コード(ISO/IEC18004)、または、適当なデバイスによって読むことが可能である類似のバーコードとして再フォーマットされ得る。再フォーマットされた有効性検証チャレンジVCM’,USERは、初期処理デバイスに送られ、スクリーンの上に表示され得、それによって、それは、有効性検証デバイス上にあるカスタムアプリケーションソフトウェア(App)によって制御されたカメラ上等、有効性検証デバイスによって取り込まれ、読まれ得る。

0058

代替的に、有効性検証チャレンジは、ネットワーク上で直接に送られ得、例えば、有効性検証デバイス上にあるカスタムAPP(アプリケーションソフトウェア)がある場合、ユーザは、有効性検証チャレンジVCM’,userが有効性検証デバイスに届くことを確実にするコマンドプッシュを入力することができ得る。そのような場合に、有効性検証の時点でユーザが物理的に存在することを保証するために、PIN、パスワード、または、認証パターンによってAPPへのアクセスを保護することに価値がある。ユーザが物理的に存在することを保証する一つの方法は、ユーザがAPPを開始するためにネットワーク上で要求を送ることであり、それによって、有効性検証チャレンジVCM’,userが、セントラル有効性検証および認証サーバから引き出され、有効性検証デバイスAPPに利用可能にされ得る。

0059

有効性検証チャレンジがどのように送られるにかかわらず、それが有効性検証デバイスで受け取られたならば、有効性検証チャレンジは、メッセージM’を再生成するために用いられ、それによって、M’は、有効性検証デバイススクリーン上に表示され得る(S212)。M’を引き出すための方法は、有効性検証チャレンジのための生成方法に依存する。例えば、M’は、成功裡のMAC有効性検証によって、または、対称暗号化または非対称暗号化技術を用いた解読によって引き出され得る。

0060

矢印5によって示されているように、プロセスにおけるこの地点において、ユーザは、かれの有効性検証デバイス上でメッセージM’を読み、それが、かれが署名するようにコミットされているメッセージMと一致することを検証することができる(S214)。例えば、上記例において、Mが購入オーダーであり、M’がPO問い合わせ番号、受領者、額等の重要なフィールドにおける情報をもったそのサマリーである場合、ユーザは、Mを特定するために、当該フィールドからの情報を提示される。有効性検証デバイス上のメッセージM’の正しい表示は、ユーザに、それがセントラルSCDによって受け取られていたのでメッセージの内容が変更されていないことの証拠と、M’の引き出しが成功裡に完了しているので有効性検証チャレンジが信頼されたソースからのものである証拠との両方を与える。実際上もしそうであれば、ユーザは、M’を承認または有効化し得、有効性検証デバイスAPPは、ユニークな有効性検証コードを計算処理し得る(S216)。M’が一致しない場合、プロセスは、署名が生成されることなく終了される。有効性検証コードは、OATH challenge response algorithm(OCRA)[RFC 6287- ISSN 2070-1721に記載]、または、 MasterCardCAP、Visa CodeSure [WO2013013262]、または、Vasco Digipass challenge response based mechanism等の等価な占有技術を含む種々の規格化された方法を用いて生成され得る。従って、有効性検証コードは、好ましくは、有効性検証デバイスとセントラル認証および有効性検証サーバとの間で共有される別のデバイス特定鍵を用いた対称暗号法を用いて生成される。有効性検証コードは、また、リプレイアタックを避けるためにノンスを用いた署名された応答であり得る。有効性検証コードは、ユーザに特有であり、好ましくは、有効性検証チャレンジを生成するために用いられた情報とは異なる情報を用いて生成されなければならない。セントラル認証および有効性検証サーバは、有効性検証コードが有効性検証デバイスからのものであることを確証する必要がある。しかし、有効性検証チャレンジと異なり、セントラル認証および有効性検証サーバが有効性検証コードの中の情報の任意の部分を再生成することは重要なことではない。従って、非対称スキームが、また、使用され得る。

0061

破線矢印6とステップ218によって示されているように、有効性検証コードは、セントラル認証および有効性検証サーバに送り返される。これは、例えば、初期処理デバイスを介して、間接的に行われる。1つのシナリオでは、ユーザは、マニュアルで、初期処理デバイス上で有効性検証コードをタイプ入力し、それが、セントラルSCDを介して、セントラル認証および有効性検証サーバに迂回される。代替的に、有効性検証コードは、ネットワーク上で、有効性検証デバイスからセントラル認証および有効性検証サーバに直接に送られ得、これによって、コードがユーザによってタイプ入力されるのを回避する。

0062

ステップ220において、有効性検証コードが、セントラル認証および有効性検証サーバによって検証される。検証は、例えば、RFC 6287に記載されたようなOATHOCRAを用いて、任意の規格技術を用いて行われる。矢印7とS222によって示されるように、検証の結果は、セントラルSCDに安全に送られる(2つが物理的に異なる場合)。

0063

最後に、矢印8によって示されているように、セントラルSCDは、有効性検証コードの検証結果をチェックする(S224)。このチェックは、セントラル認証および有効性検証サーバからのレスポンスが正しく認証されることを確証すること、検証の結果がポジティブであることを確証することを含む。このチェックが正しくないならば、プロセスはメッセージに署名することなく終了される。代替的に、全てが正常であるならば、署名が、ユーザのセントラルSCDを用いてメッセージMのために生成される(S226)。

0064

最後のステップとして、生成された署名は、従来の方法を用いて、ユーザまたは任意の信頼する者によって検証され得る(S228)。論争がある場合には、セントラル認証および有効性検証サーバのログが、ユーザが有効性検証デバイスを用いて署名にコミットしたことのシステムプルーフを生成するために用いられ得る。

0065

図3aは、セントラル署名生成デバイスがローカル署名生成デバイスに置き換えられた、図2aの構成の変形例を示す。ローカルによって、署名生成デバイスが、例えばUSBスティックまたはドングル等のユーザによって所有される(即ち、携えられる)ことを意味する。全ての他のデバイスは同じであり、同じ番号が用いられる。更に、以下により詳細に説明されるように、プロセスにおけるステップの多くは同様であり、従って、両者に共通なステップは、この実施形態に関連してはあまり詳細には説明されない。システム周りの情報の流れは、番号1から10によって示され、図3bと3cに関連してより詳細に説明される。

0066

先の構成に置けるように、矢印1によって示されるように、ユーザは、彼の初期処理デバイス上に表示されているメッセージMの内容に同意し、受け入れる(S300)。同様に、先の構成におけるように、矢印2によって示されるように、ユーザは、メッセージMのための署名を要求するために署名生成デバイスにコンタクトする(S302)。主要な相違は、要求がローカル署名生成デバイスに送られることである。

0067

再び、M’と呼ばれる、メッセージの派生されたバージョンが初期処理デバイスによって生成され(S304a)、SCDによって生成され(304b)、または、セントラル認証および有効性検証サーバによって生成される(304c)。しかし、先の構成とは対照的に、M’が初期処理デバイスによって生成される(S304a)またはSCDによって生成される(304b)場合、メッセージM’は、セントラル認証および有効性検証サーバがメッセージM’を信頼することができることを保証するために、メッセージM’がセントラル認証および有効性検証サーバに送られる前に、ローカルSCDによって認証される(S305)。認証は、署名など、任意の既知の技術によって行われ得る。この構成では、SCDとセントラル認証および有効性検証サーバとの間の安全な接続がない。従って、認証は、セントラル認証および有効性検証サーバが、メッセージM’がローカルSCDから受け取られていることを信頼できることを保証する。

0068

矢印5によって示されたような有効性検証チャレンジを生成する前に、セントラル認証および有効性検証サーバが、M’がユーザのSCDから来ることを保証するために、いくつかのオプションとしての検証を実行し得る(S307)。これらのオプションとしてのステップは、ハードウェアセキュリティモジュール(hardware security module:HSM)、または、セントラル認証および有効性検証サーバの安全なコンパウンドによって実行され得る。これらの検証は、正しい証明書がユーザによって選択され、その証明書が有効であり、ローカルSCDが、それが署名を実行する前に接続され、機能しうることを保証し得る。これらのオプションとしての検証が完了したら、有効性検証チャレンジVCM’,userが、メッセージM’とM’に関連付けられたユーザのために、セントラル認証および有効性検証サーバによって生成される(S308)。この有効性検証チャレンジは、上述のように生成される。

0069

次の数ステップは上述されている。従って、破線矢印6とステップ310によって示されたように、有効性検証チャレンジVCM’,userは、有効性検証デバイスに、直接または間接的に送られる。有効性検証チャレンジがどのように送られるかにかかわらず、それが有効性検証デバイスで受け取られれば、有効性検証チャレンジは、M’が有効性検証デバイスのスクリーン上で表示され得る(S312)ように、メッセージM’を再生成するために用いられる。矢印7によって示されているように、プロセスのこの地点で、ユーザは、彼の有効性検証デバイス上でメッセージM’を読むことができ、それが、彼がサインしようとコミットされているメッセージMと合致することを検証する(S314)。有効性検証デバイスは、次に、上述のように、ユニークな有効性検証コードを計算処理する。破線矢印8とステップS318によって示されるように、有効性検証コードが、セントラル認証および有効性検証サーバに直接または間接的に送り返される。

0070

先の構成におけるように、ステップ320において、有効性検証コードが、セントラル認証および有効性検証サーバによって検証される。しかし、矢印9とS322によって示されるように、この検証の結果は、次に、(図2aのセントラルSCDではなく)ローカルSCDに安全に送られる。安全な送信は、検証の結果に署名するおよび/または暗号化すること等による既知の技術によって達成され得る。最後に、矢印10によって示されるように、セントラルSCDが、有効性検証コードの検証の結果をチェックする(S324)。このチェックは、セントラル認証および有効性検証サーバからの応答が正しく認証されることを確証することと、検証の結果がポジティブであることを確証することとを含む。このチェックが正しくない場合、プロセスは、メッセージに署名することなく終了される。代替的に、全てが正常である場合は、ユーザは、かれが有効性検証デバイス上で承認したメッセージM’に実際に対応していることに確信を持つことができ、結果、メッセージM(または、そのハッシュ)が最終的に署名され得る。

0071

従って、ローカルSCDを用いて、デジタル署名がメッセージMのために生成される(S326)。オプションとして、セントラル認証および有効性検証サーバからの応答および/または有効性検証コードは、署名された署名属性として付与され得る。前のように、生成された署名は、これまでの方法を用いて、ユーザまたは任意の信頼する者によって検証され得る。論争がある場合には、セントラル認証および有効性検証サーバのログが、ユーザが有効性検証デバイスを用いて署名をすることにコミットされていたことのシステムプルーフを生成するために用いられる。

0072

上記構成は、ローカル署名生成デバイスを有するにかかわらず、セントラル認証および有効性検証サーバが必要とされるという不利な点を有する。図4aは、図3aの構成の変形を示し、ローカル署名生成デバイス24がセントラル認証および有効性検証サーバの機能性を提供する。この構成において、全ての動作は、ネットワーク接続を必要とすることなくローカルに完了される。署名生成デバイス24は、M上に署名をする前に、有効性検証コードを検証する。ローカル署名生成デバイスが、有効性検証デバイス12上に表示され、承認されたメッセージ上に署名を生成するためにのみ用いられ得ることを、これが保証する。ローカルで、署名生成デバイスは、USBスティックまたはドングルといった、ユーザによって所有される(即ち、携えられる)。初期処理および有効性検証デバイスは、前のものと同じであり、従って、同じ番号が用いられている。更に、以下により詳細に説明されるように、プロセスにおけるステップの多くは同様であり、従って、両者に共通なステップは単に前の説明を参照する。システム周りの情報の流れは、番号1から8によって示され、図4bと4cに関連してより詳細に説明される。

0073

先の構成におけるように、矢印1で示されるように、ユーザは、彼の初期処理デバイス上に表示されているメッセージMの内容に同意し、受け入れる(S400)。同様に、先の構成におけるように、矢印2で示されるように、ユーザは、メッセージMのための署名を要求するために、ローカル署名生成デバイスにコンタクトする(S402)。再び、M’と呼ばれるメッセージの派生されたバージョンが、初期処理デバイスによって生成される(S404a)またはSCDによって生成される(S404b)。

0074

先の構成とは対照的に、矢印3によって示されるように、セントラル認証および有効性検証サーバではなくローカルSCDが、メッセージM’およびM’に関連付けられたユーザのための有効性検証チャレンジVCM’,userを生成する(S408)。この有効性検証チャレンジは、上述と同じメカニズムを用いて生成され;唯一の違いは、それらが、セントラル認証および有効性検証サーバではなく、ローカルSCD上で実行されることである。

0075

先の構成に示されたように、破線矢印4とステップ410によって示されたように、有効性検証チャレンジVCM’,userは、直接または間接的に、有効性検証デバイスに送られる。有効性検証チャレンジがどのように送られるかにかかわらず、それが有効性検証デバイスで受け取られたら、有効性検証チャレンジは、メッセージM’を再生成するために用いられ、M’は、有効性検証デバイスのスクリーン上に表示される(S412)。矢印5で示されたように、プロセスのこの地点で、ユーザは有効性検証デバイス上でメッセージM’を読み、それが、彼が署名しようとコミットされているメッセージMと合致していることを検証できる。妥当性検証デバイスは、次に、上述のように、ユニークな有効性検証コードを計算処理する(S416)。

0076

この構成において、セントラル認証および有効性検証サーバはなく、従って、有効性検証コードは検証のためにそこに送られることはできない。従って、有効性検証コードが有効性検証デバイスからローカルSCDに直接送られるのではなく、有効性検証コードは、有効性検証デバイス上に表示され、ユーザは、有効性検証コードを初期処理デバイスに入力する。これは、破線矢印6とS418によって示される。矢印7とS420は、次に、有効性検証コードが初期処理デバイスからローカルSCDに送られることを示す。従って、有効性検証コードは、有効性検証デバイスからローカルSCDに間接的に送られる。有効性検証コードは、メッセージMに署名するために、ローカルSCDへの要求の部分として送られ得る。

0077

先の構成とは対照的に、ステップS424において、有効性検証コードは、ローカルSCDによって検証される。従って、この構成において、有効性検証デバイスとローカルSCDはお互いに登録される必要があり、有効性検証コードが有効性検証デバイスからのものであることを、ローカルSCDが確証できるように用いられることができる秘密鍵または類似の秘密をそれらが共有する。ローカルSCDと有効性検証デバイスとの間の認証は、任意の既知の方法を用い得る。例えば、秘密鍵は対称鍵、即ち、暗号化テキストを生成するための平文の暗号化と、平文に戻すための暗号化文複合化の両方に用いられ得る鍵、であってよい。秘密鍵は、ローカルSCDと有効性検証デバイスの両方の上での、好ましくは長いパスワードを入力することによる初期化フェーズまたはパスシーケンスにおいて交換され得る。しかし、秘密鍵の他の交換も可能である。秘密鍵が記憶されると、署名のための要求は、ローカルSCDにおいて秘密鍵を用いるために必要とされるアクセスコード(例えば、PIN)を含み得る。

0078

検証プロセスに続いて全てが正常であるならば、有効性検証コードが、実際に、有効性検証デバイス上で承認したメッセージM’に対応するとの確信を持つことができ、メッセージM(または、そのハッシュ)は最終的に署名され得る。従って、デジタル署名がローカルSCDを用いてメセージMのために生成される(S426)。オプションとして、M’および/または有効性検証コードは、署名された署名属性として付与され得る。

0079

上述のように、有効性検証デバイスと初期処理デバイスは、この中に記載された機能を実行するとめの特定用途コンピュータであるように、ソフトウェアによって変更されている(例えば、プログラムされる、または、構成される)任意の形態の電子デバイスであってよい。図5aは、有効性検証デバイスまたは初期処理デバイスのいずれかのコンポーネントを概略的に示す。各々は、コードおよびデータメモリ54、入力/出力システム56(例えば、ネットワークおよび/または記憶媒体および/または他の通信)、例えばキーボードおよび/またはマウスを備えるユーザインタフェース58、ユーザディスプレイ62に結合されたプロセッサ52を備える。また、図2bのステップS210に関連して上述されたように、有効性検証チャレンジのバーコードまたは類似の読取可能バージョンが生成されるときに用いられ得るオプションとしてのカメラ64が存在し得る。メモリ54に記憶されたコードおよび/またはデータは、取り外し可能な記憶媒体上に与えられてもよい。

0080

有効性検証デバイスについて、入力/出力システム56は、有効性検証チャレンジを受けるために用いられ得、または、代替的に、カメラ64が、初期処理デバイス上に表示されているバーコードから有効性検証チャレンジを獲得するために用いられ得る。プロセッサ52は、有効性検証チャレンジからメッセージM’を再生成するために用いられ得、ユーザディスプレイ62は、メッセージM’を表示するために用いられる。そして、ユーザインタフェース58は、メッセージM’が正しい場合にメッセージM’を承認するため、および、有効性検証コードを計算するために、ユーザによって用いられ得る。ディスプレイ62は、ユーザに有効性検証コードを表示し得、入力/出力システム56は、システムの適切な部分にこの有効性検証コードを通信し得る。メモリ54に記憶されたデータは、任意の入ってくるデータの検証および/または解読のために要求される必要な共有された秘密、例えば、図4aの構成におけるローカルSCDとのみ共有される、または、図2aと3aの構成におけるセントラル認証および有効性検証サーバと共有される秘密のペアを含み得る。秘密のペアは、好ましくは、メッセージM’を再生成するために入ってくる有効性検証チャレンジを解読および/または検証するための1つ、有効性検証コードを生成するための1つの、2つの異なる情報を備える。

0081

初期処理デバイスについて、ユーザディスプレイ62は、原メッセージMを表示するために用いられ得、そして、ユーザインタフェース58はメッセージMのための署名を要求するためにユーザによって用いられ得る。ユーザディスプレイ62は、また、例えばバーコードの形式で、有効性検証チャレンジを表示するために用いられ得る。ユーザインタフェース58は、有効性検証コードが署名生成デバイスに送られ得るように、有効性検証コードを入力するために用いられ得る。

0082

図5bは、署名生成デバイス(ローカルまたはセントラル)、または、セントラル認証および有効性検証サーバのコンポーネントを示す。各々は、コードおよびデータメモリ74と入力/出力システム76(例えば、ネットワークおよび/または記憶媒体および/または他の通信のためのインタフェースを備える)とに結合されるプロセッサ72を備える。メモリ74に記憶されたコードおよび/またはデータは、取り外し可能な記憶媒体上に与えられてもよい。デバイスは、また、有効性検証デバイスと共有される秘密のペアを備えるユーザデータベース78を備える。ユーザデータベースは、個別のコンポーネントとして示されているが、同じデバイスに統合され得る。デバイスは、また,ハードウェアセキュリティモジュール80を備える。HSMは、SCDの場合に、署名鍵を保護し、用いるために使用され得る。HSMは、認証および有効性検証サーバにおいて有効性検証チャレンジとコードを保護する鍵を保護し用いるために用いられ得る。

0083

図2aおよび3aの構成において、セントラル認証および有効性検証サーバのためのプロセッサ72は、有効性検証チャレンジを生成し得、入力/出力システムは、それを、有効性検証デバイスに送り得る。有効性検証コードは、入力/出力システム76を介して受け取られ得、プロセッサ72によって検証される。そして、検証の結果は、署名生成デバイスに送られ得る。

0084

全ての構成において、署名生成デバイスについて、プロセッサ72が、ユーザデータベース78に記憶された秘密情報を用いて署名を生成し得る。更に、図4aの構成において、署名生成デバイスのためのプロセッサ72は、有効性検証チャレンジを生成し得、入力/出力システム76はそれを有効性検証デバイスに送る。有効性検証コードは、入力/出力システム76を介して受信され、プロセッサ72によって検証される。

0085

図5bは、単一または複数のセントラルプロセッシングユニット、例えば、マイクロプロセッサ、から実装され得る複数の内部コンポーネントをもった単一の計算処理デバイスを示す。デバイスの機能性は、いくつかの計算処理デバイスを通して分散され得ることが認識される。また、個々のコンポーネントが、組み合わされた機能性を提供するために1つまたは複数のコンポーネントに組み合され得ることも認識される。更に、図5bに示されたモジュールデータベース、または、デバイスの任意のものが、この中に記載された機能を実行するために特定用途コンピュータであるように、ソフトウェアによって変更される(例えば、プログラムされるまたは構成される)汎用コンピュータに実装され得る。

0086

疑いなく、多くの他の有効な代替案が技量に習熟した者に生じる。発明は、記載された実施形態に限定されず、本明細書に添付された特許請求の範囲の真意と範囲の中に入る、本技術に技量を有した者にとって明らかな変更を包含することが理解される。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ