JP2021524944A - マルチパーティ計算（ｍｐｃ）による物のインターネット・セキュリティ - Google Patents

マルチパーティ計算（ｍｐｃ）による物のインターネット・セキュリティ Download PDF

Info

Publication number
JP2021524944A
JP2021524944A JP2021514484A JP2021514484A JP2021524944A JP 2021524944 A JP2021524944 A JP 2021524944A JP 2021514484 A JP2021514484 A JP 2021514484A JP 2021514484 A JP2021514484 A JP 2021514484A JP 2021524944 A JP2021524944 A JP 2021524944A
Authority
JP
Japan
Prior art keywords
devices
sas
key
communication channel
communication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2021514484A
Other languages
English (en)
Inventor
マイア ソアレス デ レゼンデ，ジョアン ミゲル
マイア ソアレス デ レゼンデ，ジョアン ミゲル
シルバ マーティンズ，ローランド ダ
シルバ マーティンズ，ローランド ダ
コエーリョ アントゥネス，ルイス フィリペ
コエーリョ アントゥネス，ルイス フィリペ
ヴィエラ ソウザ，パトリシア ラケル
ヴィエラ ソウザ，パトリシア ラケル
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Inesc Tec Instituto de Engenharia de Sistemas e Computadores Tecnologia e Ciencia
Original Assignee
Inesc Tec Instituto de Engenharia de Sistemas e Computadores Tecnologia e Ciencia
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Inesc Tec Instituto de Engenharia de Sistemas e Computadores Tecnologia e Ciencia filed Critical Inesc Tec Instituto de Engenharia de Sistemas e Computadores Tecnologia e Ciencia
Publication of JP2021524944A publication Critical patent/JP2021524944A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y30/00—IoT infrastructure
    • G16Y30/10—Security thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
    • G06F7/58—Random or pseudo-random number generators
    • G06F7/582—Pseudo-random number generators
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/46—Secure multiparty computation, e.g. millionaire problem
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

第１のデバイス（２００Ａ）と第２のデバイス（２００Ｂ）との間の通信チャネルを介した通信を確立するための方法およびデバイスが開示される。方法は、第１のデバイス（２００Ａ）と第２のデバイス（２００Ｂ）とを相互に発見することと、データ・メッセージの交換によって第１のデバイス（２００Ａ）と第２のデバイス（２００Ｂ）との間の通信チャネルの正当性確認をすること（Ｆ５、Ｆ６、Ｆ７）と、第１のデバイス（２００Ａ）と第２のデバイス（２００Ｂ）との間で秘密を交換し、次に通信チャネルを介して暗号化メッセージを交換することとを含む。

Description

関連出願の相互参照
本出願は、２０１８年５月１６日に出願されたポルトガル特許出願第２０１８１００００３４５２９号および２０１８年５月２５日に出願されたヨーロッパ特許出願第１８１７４４１２．９号の優先権および利益を主張する。
物のインターネット（ＩｏＴ）は、テクノロジが今後どのように人々と関わり合うかという概念である。これは、「スマート」デバイスが人間と対話するだけでなく、相互にも対話する、プライベート・インターネットおよび／またはパブリック・インターネットなどのネットワークに接続された「物」またはデバイスの集合である。ガートナーの研究機関によって公表されたデータは、２０２０年までには、インターネットに接続されたそのようなスマートデバイスが２５０億になるだろうと予測している。これらの物理的および仮想的な「物」は、識別属性と、物理属性と、仮想人格とを有し、現実／物理世界における事象に対して実質的に自律的に反応して人間の直接介入なしにプロセスによってそれらの事象に作用する。
この分野における指数関数的成長に伴い、いくつかのプライバシーおよびセキュリティ上の課題が存在する。具体的には、ＩｏＴデバイスの特定の特性に合わせてセキュリティ解決策を適応化する必要がある。ＩｏＴデバイスには、従来型デバイスにはないリソースの限界がある［参照文献１］。そのような限界には、ＩｏＴデバイスにおける限られたバッテリ寿命と記憶空間が含まれる。ＩｏＴデバイスに必要なセキュリティおよびプライバシー要件のセットには、ユーザおよびデバイス識別情報管理、認証、ＩｏＴデバイスのうちの異なるＩｏＴデバイス間の通信で交換されるデータの機密性、ＩｏＴデバイスのうちの許可されたもののみがＩｏＴネットワークにアクセスすることができるようにするネットワーク・アクセス制御、およびリソースおよびシステムの可用性が含まれるが、これらには限らない［参照文献２］。
現在、ほとんどの研究ＩｏＴプラットフォームおよび既存ＩｏＴプラットフォームが、デバイス管理に焦点を合わせ、認証およびセキュリティのために信頼できる集中型解決策を採用している。これらの集中型解決策は、公開鍵インフラストラクチャ（ＰＫＩ）に基づく。ＰＫＩを使用する明白な利点にもかかわらず、ＰＫＩに基づく解決策は、複雑で、費用がかかり、管理が容易ではない傾向がある［参照文献４］。さらに、ＰＫＩ方式のネットワークに接続されたデバイスには前述のリソースの限界がある。
ＩｏＴデバイスのメモリに記憶されているどのような鍵でも、物理的に奪われたＩｏＴデバイスから読み取られる可能性があり、ＩｏＴデバイスが組み込まれているＩｏＴネットワークに攻撃を仕掛けるために敵対者によって使用される可能性があるため、ＩｏＴデバイスの物理的セキュリティも問題であることがわかっている［参照文献３］。
ＰＫＩは、ネットワーク（上述のＩｏＴネットワークなど）内のセキュリティ証明書の正当性確認についてもっぱら証明機関（ＣＡ）のみに依存している。ＣＡは、ネットワークのインフラストラクチャ内の単一障害点に相当する。障害点は様々なプロトコルに存在することがわかっているが、ネットワークがネットワークに対するいかなる攻撃に対してもより耐性を備えるようになることを可能にするためには、これらの障害点は（ＣＡにおけるように）単一ではないかまたは集中化されていないことがきわめて望ましい。ＰＫＩは、ＣＡの公開鍵が露出された場合、完全かつ不可逆的に侵害される。公開鍵を入手した攻撃者は、新たな証明書を容易に発行することができ、したがって、侵害されたネットワークにおいてなりすましをして、いわゆる中間者（Ｍａｎ−ｉｎ−ｔｈｅ−Ｍｉｄｄｌｅ（ＭｉｔＭ））攻撃を行うことができる。ＭｉｔＭ攻撃は、攻撃者が、実際に互いに直接通信をしているものと思っているネットワークにおける２者間の通信を秘密裏に中継し、場合によっては変更を加える場合である。例えば、サーバ証明書の単純な露見の場合、攻撃者がその期間にネットワークを侵害することができるいわゆる「攻撃ウィンドウ」が開かれる。この攻撃窓は開いたままとなり、その露見したサーバ証明書は無効にされるが、これは、例えば攻撃がしばらく通知されない場合、ただちには行われない可能性がある。
ＰＫＩにおいて発生することがわかっているもう一つの問題は、よく管理されていないＣＡが、特定のドメインの所有権を正しく検証せずに、そのドメインのための証明書に署名する場合である。
前述の限界を考えると、ＰＫＩにおいて基礎にある前提は、必ずしもＩｏＴネットワークおよびＩｏＴデバイスにとって最適ではない。
ディフィー・ヘルマン（ＤＨ）鍵交換は、ネットワークにおいてパブリック・チャネルを介して暗号鍵をセキュリティ保護された状態で交換する方法であり、ネットワークを介して通信したい２者間の共有秘密の確立に基づいている。ＤＨ鍵交換は、２者（典型的にはアリスとボブと呼ばれる）がそれぞれ、２者に秘密に保たれる秘密パラメータと、非秘密に保たれ、２者間で合意される開始パラメータとを設定する。開始パラメータは、両者の側で秘密パラメータと混合され、次に、公開鍵として交換される。公開鍵の交換後、公開鍵は自分の秘密パラメータと混合され、その後両者は通信の暗号化のために使用可能な同一の値を持つ。残念ながら、ＤＨ鍵交換は通信するパーティの認証を与えないため、ＤＨ鍵交換もＭｉｔＭ攻撃に対して脆弱である。したがって、攻撃者は、ボブとアリスの両方、すなわち通信パーティになりすますことができる。
２者が互いに直接通信して、ショート認証文字列（Ｓｈｏｒｔ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｔｒｉｎｇ（ＳＡＳ））を渡して確認することによってその身元を確認することができるいくつかのプロトコルが知られている。これらのプロトコルには、Ｚリアルタイム・トランスポート・プロトコル（Ｚ Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＺＲＴＰ））［参照文献．９］およびジャグリングによるパスワード認証鍵交換（Ｐａｓｓｗｏｒｄ Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ ｂｙ Ｊｕｇｇｌｉｎｇ（Ｊ−ＰＡＫＥ））［参照文献．５および７］があり、人間の対話と手動プロビジョニングという前提に基づく。しかし、このような知られているプロトコルは、ＩｏＴデバイスのペアの間では実際的ではない人間の対話に基づくため、ＩｏＴデバイスとの通信には適さない。
提供されているその他の解決策としては、ＰＡＫＥ（パスワード認証鍵合意（Ｐａｓｓｗｏｒｄ−Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ）プロトコルがある。現在、最も高度なアルゴリズムは、公開鍵暗号化に基づく鍵交換を行わず、低エントロピー・パスワードの使用を可能にする。参照文献６では、３つの最新ＰＡＫＥプロトコルについて説明されている。同論文では、ＯｐｅｎＳＳＬ環境でデフォルトとして採用された、Ｊ−ＰＡＫＥプロトコルよりも効率的な２つのプロトコルも開示されている。
Ｊ−ＰＡＫＥプロトコル［参照文献５および７］は、２者間でセキュリティ保護された通信を確立するためにＰＫＩまたは第三者を必要としない共有パスワードの概念に基づく。Ｊ−ＰＡＫＥは、鍵合意のための楕円曲線ＤＨと、シュノア非対話型ゼロ知識（Ｓｈｎｏｒｒ Ｎｏｎ−Ｉｎｔｅｒａｃｔｉｖｅ Ｚｅｒｏ−Ｋｎｏｗｌｅｄｇｅ（ＮＩＺＫ））署名［参照文献８］証明機構を使用して、２者を認証し、パスフレーズに基づき２者間の共有秘密を確立する。Ｐａｌｅ Ｍｏｏｎウェブ・ブラウザ、Ｂｏｕｎｃｙｃａｓｔｌｅ（バージョン１．４８以降）における軽量ＡＰＩ、およびＴｈｒｅａｄ（ＩｏＴ無線ネットワーク・プロトコル）など、依然としてＪ−ＰＡＫＥを使用している一部のサービスもある。このプロトコルは、ＦｉｒｅＦｏｘ Ｓｙｎｃ、ＯｐｅｎＳＳＨ、およびＯｐｅｎＳＳＬによっても以前にサポートされていたが、２０１４年以後は削除されている。
Ｍｏｈｓｅｎ Ｔｏｏｒａｎｉ［参照文献１２］によってすでに公開されているいくつかの知られているＪ−ＰＡＫＥの問題がある。参照文献１２は、ＦｉｒｅＦｏｘ Ｓｙｎｃによって使用されていたＪ−ＰＡＫＥの分析を示しており、Ｊ−ＰＡＫＥにおける脆弱点を特定している。例えば、Ｊ−ＰＡＫＥは、パスワード侵害なりすまし攻撃に対して脆弱であり、再生および未知の鍵共有（Ｕｎｋｎｏｗｎ Ｋｅｙ−Ｓｈａｒｅ（ＵＫＳ））攻撃に関するその他の短所がある。Ｊ−ＰＡＫＥは、ＯｐｅｎＳＳＬおよびＯｐｅｎＳＳＨにも組み込まれているが、実装時に問題が報告されている［参照文献２５］。
ショート認証文字列を使用したデバイス・ペアリング［参照文献２２］は、ＳＡＳを使用した秘密の真正性の合意および検査に基づく２デバイス・ペアリング機構である。このプロトコルは、発見、合意および認証の３段階を含む。ペアリング・サービスが開始すると、サーバが選択されたインスタンス名の公開を開始する。クライアントが、その名前と、対応する接続パラメータとを発見する［参照文献２２］。サーバが発見された後、クライアントとサーバは、クライアントとサーバがＳＡＳを生成する暗号化プロトコルを使用して共有秘密について合意することができるようにする、トランスポート層セキュリティ（ＴＬＳ）セッションを使用する。この段階の完了後、ＳＡＳによるペアリングの正当性を確認するために使用される認証段階がある。この認証段階では、手動検証、すなわちユーザが、通信を行いたい両方のデバイス（サーバとクライアント）が同じ文字列を表示することを検証する必要がある検証により、ＳＡＳの比較が行われる。この代わりにサーバとクライアントがクイック・レスポンス（ＱＲ）コード（登録商標）をサポートしている場合は、サーバが、ＳＡＳの符号化を備えたＱＲコード（登録商標）を表示し、クライアントがＳＡＳの値をスキャンすることができ、スキャンされた値をローカルで計算された値と比較することができる。
ＺＲＴＰ［参照文献９］は、セキュア・リアルタイム・トランスポート・プロトコル（ＳＲＴＰ）セッションを確立するための鍵交換およびパラメータについて合意するために使用されるセッション設定段階を含む、２点間マルチメディア通信プロトコルである。このＺＲＴＰプロトコルは、デジタル証明書には基づかず、各セッションで生成された（前述の）ＤＨ鍵に基づく。これらのＤＨ鍵は、ＳＲＴＰセッションのためのセッション鍵およびパラメータの生成に寄与する。ＺＲＴＰプロトコルは、最初に、セッション開始プロトコル（ＳＩＰ）などのシグナリング・プロトコルを使用する必要があるが、鍵ネゴシエーションはＺＲＴＰ実装のみによって行われる。しかし、ＤＨアルゴリズムだけでは、ＭｉｔＭ攻撃に対する十分な保護を提供しない。ＺＲＴＰプロトコルでの鍵交換において両方のピアを認証するために、両方の電話に配信されるＳＡＳが使用され、両端によって口頭で比較される。ＳＡＳが同じ場合、ユーザの両方が、その鍵を受け入れるためにボタンを押す必要がある。
米国特許第７，７３０，３０９号は、セキュア電話プロトコルのための方法およびシステムを教示している。セキュア電話プロトコルは、キャッシュされて、その後、別個のセキュア通話のために使用される一連の長いセッション鍵を認証するために再使用される、共有秘密値を含むことができる。これは、ユーザによる音声認証の必要なしに、暗号化鍵の連続性を可能にする。当該特許のシステムは、通話設定時にＤＨ鍵交換を使用し、したがって上述の限界という欠点がある。
上記のように、既存の解決策は、ＩｏＴネットワークにおけるＩｏＴデバイス間の、データを含むメッセージの交換のための十分な認証および暗号化方法を提供しない。
ショート認証文字列（ＳＡＳ）の正当性確認および通信チャネルのセキュリティのためにユーザによる人間の対話を必要としないＳＡＳの交換による、自律的相互ペアリングのための新しい手法が必要である。
本開示は、２つのデバイス間のマルチパーティ計算を使用した自律的検証による、いわゆる鍵交換のためのシステムおよび方法を提供する。鍵交換は、ＩｏＴデバイス、ボイス・オーバＩＰ（ＶｏＩＰ）プロトコルを実装するデバイス、またはネットワーク内のその他のユニットなどの、任意の２者間にセキュリティ保護された通信を確立するために使用される。このシステムおよび方法は、例えばディフィー・ヘルマン（ＤＨ）鍵交換に基づく。しかし、本明細書に記載のシステムおよび方法は、ＰＫＩ、または証明機関などの信頼できる第三者の存在を必要としない。
マルチパーティ計算（ｍｕｌｔｉ−ｐａｒｔｙ ｃｏｍｐｕｔａｔｉｏｎ（ＭＰＣ））は、非集中型プライバシー保護計算フレームワークを構築するための基本ビルディング・ブロックを提供するための適切な選択肢となる。ＭＰＣの目標は、パーティが自分のプライベート入力の何らかの結合関数を計算することができるようにすることである［参照文献１３］。このプロトコルはいくつかのセキュリティ特性を保持する必要がある。すなわち、パーティのうちの一部が積極的または受動的な悪意ある敵対者によって侵害された場合でも［参照文献１４］、すなわち、関数自体の出力以上の情報を明らかにすることなく、出力の正確さと入力のプライバシーを保持する必要がある。
本開示の方法は、第１のデバイスと第２のデバイスとの間の通信チャネルを介した通信の確立のために以下のように実装される。第１のデバイスと第２のデバイスとはローカル・デバイスであり、例えば、複数のそのようなデバイスを含むＩｏＴネットワーク、またはＶｏＩＰネットワークの構成要素であり得る。ＶｏＩＰネットワーク内のデバイスは、音声方式のメッセージの送信のためのデバイスである。
この方法は、例えば、第１のデバイスと第２のデバイスとの間で開始メッセージおよび肯定応答メッセージを交換することによる、第１のデバイスと第２のデバイスの相互発見を含む。この相互発見は、第１のデバイスと第２のデバイスとの間の直接通信としてのメッセージの自動交換によって実施され得る。例えば前述のＶｏＩＰネットワークにおいて使用される１つの選択肢は、第１のデバイスと第２のデバイスとの間の通信チャネルを認証することができるＳＩＰサーバと呼ばれる集中型サーバの使用である。次に、第１のデバイスと第２のデバイスの間で秘密セッション鍵が確立される。
その後、第１のデバイスにおいて第１のＳＡＳを、第２のデバイスにおいて第２のＳＡＳを計算し、次に、第１のＳＡＳを第１のデバイスにおける第１のＭＰＣモジュールに、第２のＤＡＳを第２のデバイスにおける第２のＭＰＣモジュールに挿入することによって、第１のデバイスと第２のデバイスの間の通信チャネルがその後正当性確認される。マルチパーティ通信（ＭＰＣ）モジュールが、第２のＭＰＣモジュールにおいて第１のＳＡＳ、および第１のＭＰＣモジュールにおいて第２のＭＡＳとを評価することによって、通信チャネルのセキュリティを確認する。その後、マルチパーティ計算を使用して第１のデバイスと第２のデバイスとの間で共有秘密が確立され、暗号化されたメッセージを通信チャネルを介して交換することができる。
本開示の一態様では、開始メッセージと肯定応答メッセージの交換による認証は、第１のデバイスと第２のデバイスとのうちの少なくとも一方の乱数識別子を生成することを含む。したがって、デバイスは、通信の交換のための通信セッションごとに異なる識別子を受信する。前述のように、ＶｏＩＰネットワークでは、ＶｏＩＰプロトコルを使用することができるデバイスの識別子を知っている、いわゆるＳＩＰサーバ（ＳＩＰ＝セッション開始プロトコル）によって相互発見が行われることになる。ＶｏＩＰネットワークにおけるその後のデータ転送は、ピア・ツー・ピア方式で行われる。
この方法は、マルチパーティ比較による比較の成功後に、第１のデバイスから第２のデバイスに確認メッセージを送信し、この第２のデバイスから第１のデバイスに確認メッセージを送信することをさらに含む。
ＳＡＳは、この方法の一実装形態では、第１のデバイスと第２のデバイスの両方で同一であり、通信チャネルの正当性確認を実装するマルチパーティ通信モジュールが、第１のデバイスから受信したＳＡＳが第２のデバイスにおいて生成されたものと等しいことを調べるようになされることに留意されたい。
本開示の一態様では、第１の秘密鍵は前の第１の秘密鍵から生成され、第２の秘密鍵は前の第２の秘密鍵から生成され、本発明の他の態様では、通信チャネルを介したすべてのメッセージの交換前に通信チャネルの正当性確認が行われる。さらなる一態様では、通信チャネルの正当性確認は、通信チャネルを介した複数のメッセージの交換後にのみ実施される。
本開示は、ネットワークにおけるローカル・デバイス間のセキュリティ保護された通信を可能にするためにこの方法を採用するネットワークも教示する。デバイスは、通信チャネルを介して複数のデバイスのうちの他のデバイスのうちの１つまたは複数のデバイスにメッセージを送信するための送信器と、複数のデバイスのうちの他のデバイスのうちの１つまたは複数のデバイスから通信チャネルよりメッセージを受信するための受信器と、生成されたＳＡＳを受信したＳＡＳと比較することによって通信チャネルと複数のデバイスのうちの別の１つのデバイスとを認証し、セッション鍵を生成するためのマルチパーティ計算モジュールと、生成されたセッション鍵を使用してメッセージを暗号化するための通信モジュールとを含む。
デバイスは、複数のセッション鍵を記憶するためのストレージもさらに含むことができ、デバイスを識別する擬似乱数を生成するための擬似乱数生成器もさらに含み得る。
２者間の第１の通信方式を示す図である。
２者間の第２の通信方式を示す図である。
２つのデバイスを備えるネットワークの概要を示す図である。
Ｒａｓｐｂｅｒｒｙ Ｐｉプロセッサである２つのデバイスの接続を示す図である。
以下、本発明について図面を基に説明する。本明細書に記載の本発明の実施形態および態様は例に過ぎず、特許請求の保護範囲をいかなる点でも限定しないことを理解されたい。本発明は、特許請求の範囲およびその均等物によって定義される。本発明の一態様または一実施形態の特徴は、本発明の異なる一態様もしくは、態様および／または特徴と組み合わせることができることを理解されたい。
本明細書に記載の製作物は、ネットワーク、より具体的にはＩｏＴネットワークおよびＶｏＩＰネットワークにおける２つの（ローカル）デバイス間のセキュリティ保護されたピア・ツー・ピア・データ交換のためのシステムおよび方法の設計および実装に関係する。このシステムおよび方法は、２つのデバイス間の通信の認証のための非集中型解決策であり、従来技術のＰＫＩとは異なり集中型解決策ではなく、本明細書のシステムおよび方法は単一障害点を有しない。ピア・ツーピア・データ交換での使用は、１つまたは複数の中央サーバが存在し、ローカル・デバイスと通信することもできるネットワークにおけるこのシステムおよび方法の使用を排除しない。
このシステムおよび方法は、軽量アーキテクチャを有し、したがって、追加オーバーヘッドなしに、ＩｏＴネットワークにおける複数の個別ＩｏＴデバイスおよびその他のユニットを備えたＩｏＴ環境のための解決策を提供する。このシステムおよび方法は、異なる要件に合わせて適応化可能である。後述するように、ＩｏＴネットワークのユーザは速度を優先させるか、または、実行時オーバーヘッドを増加させることになる追加的セキュリティ検査を導入することができる。
このシステムおよび方法は、人間の介入に依存せず、したがってセキュア・ボイス・オーバＩＰ（ＶｏＩＰ）通信のために使用することができる。この方法は、ＺＲＴＰ ＶｏＩＰ用途に適応化可能であり、それによって人間の介入の必要をなくすことができ、または、後述するように通信チャネルの正当性確認のために適応化可能である。
このシステムおよび方法は、マルチパーティ計算（ＭＰＣ）の概念を利用する。これは、１９８２年にセキュア２パーティ計算の一形態として正式に紹介され、１９８６年にＡｎｄｒｅｗ Ｙａｏの文献によって一般化された、暗号化のサブ分野である［参照文献１３、３０および３１］。ＭＰＣの背景にある考え方は、計算を秘密裏に行うことである。この場合、パーティｉが入力ｔｉを担当する、Ｎパーティが関数
ＥＱ ｆ（ｔ＼ｓ＼ｄｏ５（１）＼，．．．＼，ｔ＼ｓ＼ｄｏ５（Ｎ））＝Ｓ （式１）
を計算したいとする。
目標は、パーティのいずれも、ペア（ｔｉ；Ｓ）、すなわち入力ｔｉおよびＳ、関数ｆｆの結果以外の情報を取得することができないことである。パーティｉからのいかなる入力ｔｉも他のパーティのいずれにも明らかにされ得ず、各パーティはその出力のみを受信する。この関数の非限定的な一例は、ＭＰＣモジュールにおいて実装される等価関数である。２パーティ、すなわち２つのＩｏＴデバイスがそれぞれ入力ｔ１およびｔ２を有するとする。ＭＰＣモジュールは、２つのＩｏＴデバイスのそれぞれから個別に対応する値ｔ１およびｔ２を受信する。ＭＰＣモジュールは、ｔ１とｔ２の値が等しい場合に値Ｓ＝１を返し、値ｔ１とｔ２が等しくない場合に値Ｓ＝０を返す。後者の場合（すなわちＳ＝０）、これは、中間者攻撃が存在し、２つのＩｏＴデバイス間の通信がセキュリティ保護された状態であると信頼することができないことを意味する。この概念は、ＶｏＩＰプロトコルを実装するデバイスなど他のパーティに合わせて適応化することもできる。
ＭＰＣプロトコルが保護された状態であるためには、ＭＰＣプロトコルに存在する必要があるいくつかの特性がある。ＭＰＣプロトコルは、プライバシーを保証する必要があり、これはパーティｉの入力ｔｉを（パーティ自身の他には）誰にもわからないように、すなわち、各パーティｉが、要求された問題の答えである式１に示す関数の出力Ｓのみを知るように保証することを意味する。一例として、明らかにされる唯一の入札価格が最高値入札者の入札価格であるオークションを挙げる。他のすべての入札価格が落札価格よりも低かったということを導き出すことは明らかに可能である。しかし、これは失敗した入札に関して明らかにされる唯一の情報でなければならない。ＭＰＣプロトコルが持っている必要があるもう一つの特性は、それによって各パーティｉが正しい出力Ｓを受信することが保証されなければならない正しさである。オークションの例では、これは、最高入札価格のパーティｉが落札することを保証され、競売人を含めてどのパーティもこの結果を変更することができないことを意味する［参照文献３２の記載を参照］。
本明細書のシステムおよび方法は、ＰＫＩシステムの複雑さまたは信頼できる第三者の使用を克服するために、ＤＨ鍵交換に基づく。導入部で述べたように、ＤＨのみでは認証を保証することはできず、ＤＨにはＭｉｔＭ問題がある［詳細については参照文献１０を参照］。
Ｚｉｍｍｅｒｍａｎｎ Ｐ．等［参照文献３４］は、「ダブル・チェック」を使用することによるこのＭｉｔＭ問題の解決策を提案している。このダブル・チェックは、ボイス・オーバー・インターネット・プロトコル（ＶｏＩＰ）通信（または、実際に音声チャネルを介した音声通信を可能にする任意のその他のプロトコルによる通信）において電話でＳＡＳを声に出して読み、パーティがＳＡＳを口頭で比較することができるようにするために、ＰＫＩシステムにおけるユーザのそれぞれのためにＳＡＳを表示することにより、ＭｉｔＭ攻撃のいずれの検出も可能にする。ユーザは、ＳＡＳが等しいことを確定するために、例えばタッチスクリーン上の「ｏｋ」ボタンまたはキーボードのリターン・キーを能動的に押す必要がある。しかし、この解決策（ＺＲＴＰプロトコルと称する）は、このプロトコルを音声チャネルなしに、したがっていかなる聴覚または口頭の通信も可能ではない状態で、純粋なデータ交換用に適応化する可能性を欠いている。言い換えると、音声による比較というＺｉｍｍｅｒｍａｎｎの考え方を使用したデータの交換のためのプロトコルは、ユーザからの介入なしにＳＡＳをセキュリティ保護された状態で自動的に交換することができる確立された音声チャネルまたはセキュア・チャネルがないため、使用することができない。ＺＲＴＰプロトコルの１つのさらなる問題は、「無精な」または「無責任な」ユーザが、ＳＡＳが等しいことを実際に検証せずにＳＡＳを単純に確定する可能性があることである。
本明細書のシステムおよび方法は、暗号化のＭＰＣサブ分野に基づいて追加的セキュリティ層を追加することによってこの認証問題を解決する。この追加的セキュリティ層は、２者（またはそれ以上の）のパーティを含み、それらのパーティのうちの各パーティがそれぞれの入力を有する。ここで、パーティの両方が、データへの自分の入力をパーティのうちの他のパーティに、またはネットワーク全体に明らかにすることなく、１つのデータに関する何らかの計算を行いたいとする。ＳＡＳは人間の介入なしに自動的に秘密裏に比較する必要がある。さらに、きわめて機密性の高い通信の場合、このダブル・チェックがきわめて重要であるため、ＳＡＳの正当性が常時、保証される。ＳＡＳの自動比較は、無精または無責任なユーザが実際にその正当性を調べることなくＳＡＳを確定するリスクもなくす。
図１Ａに、本明細書のシステムおよび方法を使用する図２に示すＩｏＴネットワークにおける２つのデバイス（２００Ａと２００Ｂ）間の通信方式を示す。図１Ｂに、２つのデバイス２００Ａと２００Ｂがボイス・オーバＩＰプロトコルを使用して通信するためのデバイスである場合の通信方式の適応化形態を示す。このような場合、２つのデバイス２００Ａおよび２００Ｂはスマートフォン、タブレット、またはコンピュータであり得るが、これは本発明を限定するものではないことを理解されたい。
図２に、互いに通信することができ、メッセージの形態でデータを互いに交換することができるデバイス２００Ａおよび２００Ｂを示す。メッセージは、純粋にデータ・メッセージであってよく、またはＶｏＩＰプロトコルを使用したボイス・データを有するパケットであってもよい。２つのデバイス２００Ａおよび２００Ｂは、その機能については後述するマルチパーティ計算モジュール２１０と、セッション鍵を記憶し、キャッシュするための識別子ファイル２２０とを含む。２つのデバイス２００Ａおよび２００Ｂは、送信器２４０および受信器２５０と、電源２６０も含む。２つのデバイス２００Ａおよび２００Ｂは、例えば利用可能な記憶容量と電力とが限られているセンサである。
２つのデバイス２００Ａと２００Ｂの間の図１Ａの通信方式は、ステップＦ１からＦ４でデバイス２００Ａおよび２００Ｂの両方が、送信器２４０と受信器２５０とを使用して自動的にＨＥＬＬＯおよびＨＥＬＬＯａｃｋ（ＨＥＬＬＯメッセージの受信の肯定応答）メッセージを交換することで開始する。このメッセージの交換は、ユーザからの介入なしに行われ、図中で段階１として示されている。これらのＨＥＬＬＯメッセージおよびＨＥＬＬＯａｃｋメッセージでは、２つのデバイス２００Ａおよび２００Ｂの両方の識別情報が互いに対して明らかにされる。識別情報は、疑似乱数生成器（ＰＲＮＧ）を使用して生成され、この識別情報は段階１で正当性確認される。段階１におけるこのメッセージの交換後、段階２の鍵合意交換が、ステップＦ５のデバイス２００Ｂからデバイス２００Ａへのコミット・メッセージで開始することができる。図１Ａに示す方式は、デバイス２００Ｂが開始側であることを想定している。デバイス２００Ｂとデバイス２００Ａとの間で鍵について合意するために、ここで実施可能な手法は２つある。
第１の手法では、デバイス２００Ａとデバイス２００ＢとがＤＨ交換により新しい共有秘密を交換する。これはステップＦ６およびＦ７に示されている。第２の手法では、デバイス２００Ａと２００Ｂとの間で前に交換された共有秘密がすでに存在するため、デバイス２００Ａとデバイス２００Ｂは新たな共有秘密を交換する必要がない。その結果、この第２の手法ではデバイス２００Ａおよび２００ＢによりＤＨ計算が省かれる。しかし、デバイス２００Ａおよび２００Ｂに記憶されているいくつかの共有鍵のうちのどの１つの共有鍵を使用すべきかを判断するために、ステップＦ６およびＦ７におけるいわゆるＤＨＰａｒｔ１メッセージとＤＨＰａｒｔ２メッセージが、やはりデバイス２００Ａと２００Ｂとの間で交換される。ＤＨＰａｒｔ１メッセージおよびＤＨＰａｒｔ２メッセージは、ＺＲＴＰプロトコルで定義されており、公開ＤＨ値である。ＤＨ値（ｈｖｉおよびｐｖｒ）の代わりに、デバイス２００Ａと２００Ｂは、保持されている秘密鍵とともにノンスを使用して鍵マテリアルを導出する［参照文献２６］。これは、ＲＦＣ文書６１８９ ＺＲＴＰ：Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ ＦｏｒｃｅのＭｅｄｉａ Ｐａｔｈ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ ｆｏｒ Ｕｎｉｃａｓｔ Ｓｅｃｕｒｅ ＲＴＰ（ユニキャスト・セキュアＲＴＰのためのメディアパス鍵合意）（ＩＳＳＮ ２０７０−１７２１）に詳細に記載されている（４．４１．１節参照）（ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６１８９＃ｓｅｃｔｉｏｎ−４．４．１．１からダウンロード可能）。
図１Ｂの通信方式は、図１Ａのものと類似しているが、段階１におけるＨｅｌｌｏメッセージの送信とＨｅｌｌｏＡＣＫ応答の受信とによるデバイス２００Ａと２００Ｂとの間の通信チャネルの発見が行われない点が異なる。２つのデバイス２００Ａおよび２００Ｂは両方とも（中央サーバである）ＳＩＰサーバに知られており、したがって段階１は、ＳＩＰサーバから（ローカル・デバイスである）２つのデバイス２００Ａおよび２００Ｂのうちの他方のデバイスへの２つのデバイス２００Ａおよび２００Ｂの識別情報の交換を含む。中央ＳＩＰサーバを使用した２つの（ローカル）デバイス２００Ａおよび２００Ｂの識別情報の交換後、２つの（ローカル）デバイス２００Ａと２００Ｂとの間で直接データを交換することができる。
これらのステップＦ６の完了後、段階３で、デバイス２００Ａおよび２００Ｂのそれぞれにおけるマルチパーティ計算（ＭＰＣ）モジュール２１０を使用して、上述のように比較によってＳＡＳの自動正当性確認が行われる。ＳＡＳは、２つのデバイス２００Ａおよび２００Ｂのセッション鍵から生成される一連の文字と数字である。ＳＡＳ値の生成については、ＺＲＴＰ ＲＦＣ（ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６１８９＃ｓｅｃｔｉｏｎ−４．５．２）に記載されており、ＫＤＦがＨＭＡＣを使用する（ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６１８９＃ｓｅｃｔｉｏｎ−４．５）。デバイス２００Ａと２００Ｂとの間で前にネゴシエートされたセッション鍵に相違があれば、２つのデバイス２００Ａと２００ＢとにおいてＳＡＳの異なる値が生成されることになる。
上述の非限定的な場合では、ＭＰＣモジュール２１０は、デバイスで生成されたＳＡＳが他のデバイスから受信したＳＡＳと等しいか否かを検査する等価関数を実装し、ＭＰＣモジュール２１０は、この等価性が検証された場合、すなわち２つのデバイス２００Ａおよび２００Ｂで生成されたＳＡＳが同じである場合に値Ｓ＝１を返し、したがって２つのデバイス２００Ａと２００Ｂとの間に通信が確立される。次に、２つのデバイス２００Ａおよび２００ＢはステップＦ８からＦ１０で、他方のデバイスがそのＳＡＳを受け入れ、検証したことを示す確認メッセージを２つのデバイス２００Ａおよび２００Ｂのうちの他方に送信することができる（段階４）。最後に、通信プロトコルは、このセキュリティ保護されたセッションでデータの送信を開始する準備が整う。値Ｓ＝０の場合、正当性確認が失敗したことを示し、中間者攻撃の可能性があり、デバイス２００Ａと２００Ｂとの間には通信が確立されない。
この方法およびシステムは、将来の機密通信を保証するために、何らかの追加的セキュリティおよびプライバシー特性を前方秘匿性として利用する。例えば、２つのデバイス２００Ａおよび２００Ｂが異なる時点で互いに複数の接続を行う場合、この方法およびシステムは、同じ鍵が後続のセッションで使用されないように、それぞれのセッション間で鍵をローテーションさせる。このようにすることで、複数の接続にわたって異なる通信に使用される鍵は異なる。
デバイス２００Ａおよび２００Ｂのそれぞれにおける識別子ファイル２２０は、秘密セッション鍵を計算するために使用される対称鍵をキャッシュし、これらの秘密セッション鍵はセッションごとに変わる。前方秘匿性と呼ばれる特性である、将来および現在のセッション鍵の導出のために使用され、また使用されることになるローカル・シードに、攻撃者がアクセスするとする。攻撃者は、この前方秘匿性の特性のために、２つのデバイス２００Ａと２００Ｂとの間の通信におけるデータの以前の交換のいずれも再現または再生することができないことになる。攻撃者は、アクセスされたローカル・シードから以前のセッションのための秘密セッション鍵を再計算することができない。言い換えると、単一の通信が侵害された場合、その単一の通信（メッセージの交換）のみが侵害されるが、異なる通信またはセッションにおけるメッセージの他の交換は侵害されないことになる。これは、その単一通信セッションのためのセッション鍵が何らかの形で「漏洩」し、その後、セッション鍵のこの漏洩が現在の通信より前のすべての以前の通信の機密性を侵害しない場合に起こり得る。
このようにして、このシステムおよび方法は、デバイス２００Ａおよび２００Ｂが通信の前にＳＡＳを交換する手間をかけない場合であっても、以下の段落で説明するような鍵連続性の一形態に基づいてＭｉｔＭ攻撃に対抗する一定の適切な認証があるため、通信における追加的保護を与えることができる。
鍵連続性という考え方は、セッション鍵がそのセッション中の通信の交換のために１回しか使用されないが、そのセッション鍵自体が、通信の交換による後続セッションのためのセッション鍵を生成するためのシードとして使用されることである。後続のセッションのためのこのセッション鍵は、その後、さらなる（後続）セッション鍵の生成のためのシードとして使用されるというように、以降同様に使用される。言い換えると、古いセッション鍵が新しいセッション鍵を生成するために使用され、その結果、使用のたびにセッション鍵の複雑さが増し、セッション鍵はより堅牢になる。
デバイス２００Ａと２００Ｂとの間のセッション鍵のネゴシエーションは、ＳＡＳとして文字と数字のシーケンスを生成することによって行われる。ＳＡＳのサイズは定義することができる。上述のように、ＳＡＳはデバイス２００Ａと２００Ｂの両方で等しくなければならない。ＺＲＴＰの場合、ＳＡＳとして使用されている音声を捕捉し、復号しようと試みると、文字と数字のシーケンスを異ならせることになる。シーケンスは、デバイス２００Ａと２００Ｂとの間で明らかにネゴシエートされたセッション鍵に相違があればＳＡＳの異なる値が生成されることになるように、両方のデバイス２００Ａおよび２００Ｂの初期鍵から導出される数学関数である。
ＩｏＴネットワークにおけるＩｏＴデバイスの数がますます増加しており、デバイス２００Ａ、２００Ｂのそれぞれに事前にセッション鍵を個別に提供する必要がないようにセッション鍵の自動的な提供が必要であるため、この鍵連続性解決策はＩｏＴネットワークの環境に適している。また、この解決策により、ＰＫＩを使用せずにエンド・ツー・エンドのプライバシーが得られる。
このシステムおよび方法は、表１に示すようなこのシステムの３つの異なる可能なモードを有する。ユーザは、これら３つのモードのうちのいずれの１つのモードが、対象とする実施に最適であるかを選択することができる。
この第１の使用モードは、「鍵連続性なしモード」と称する。この第１のモードは、いずれのデバイスにもキャッシュがない実装形態が示唆されているＺＲＴＰ草案の４．９．１節［参照文献９］に示されているＺＲＴＰの既存の機構を利用する。この特徴により、（ＺＲＴＰ ＤＨモード［参照文献９］にも基づいてこのシステムおよび方法は常にＤＨモードで実行されることができる。この第１のモードでは、セッションを確認するためにＭＰＣを使用してデバイスの間でＳＡＳを比較することが必須である。
この第１のモードは、いくつかのセキュリティ上の課題が解決された安全な状態である。セキュリティ上の課題の１つは、敵対者がローカル共有秘密を得ることが不可能であることである。この第１のモードでは、デバイス２００Ａと２００Ｂとの間の接続は、デバイス２００Ａと２００Ｂが２つのデバイス２００Ａと２００Ｂの間の通信のためのセッション鍵について事前に合意したことがない、常に新しい接続とみなされる。したがって、この新しい接続は、前の接続から「導出」されず、新たな鍵を作成するために鍵連続特性を使用することはできない。この第１のモードは、デバイス２００Ａまたは２００Ｂのいずれにおいてもメモリ内に、新たな鍵の導出元となる、前に使用された鍵を記憶するためのいかなる追加の記憶域も必要としない。しかし、この第１のモードは新たな接続ごとにＭＰＣを行う必要があるため、２つのデバイス２００Ａと２００Ｂとを接続するネットワークにオーバーヘッドを加える。この追加のオーバーヘッドを考慮に入れる必要があり、デバイス２００Ａおよび２００Ｂにおける追加の記憶域を備えるという他方の要件との兼ね合いを図る必要がある。
第２のモードは、通常モードであり、ＺＲＴＰ ＲＦＣの４．４．２節［参照文献９］に示されている、事前共有モードとして示されるＺＲＴＰの既存の機構に基づいている。
この第２の、通常モードでは、ＭＰＣを使用してすべての反復回でＳＡＳを常に比較する必要がないように、鍵連続性の特徴が使用される。しかし、この比較は、２つのデバイス２００Ａと２００Ｂとの間でＮ回の接続が行われた後ごとに行われることになる。Ｎの値はユーザが定義することができる。非限定的な一態様では、Ｎのデフォルト値は１０である。言い換えると、通信の１０回の交換後ごとに、プロトコルが期待通りに実行されていることが検証される。
この第２のモードでは、前方秘匿性と鍵連続特性とが保持される。
第３のモードは、反復回ごとに、すなわち、２つのデバイス２００Ａと２００Ｂとの間の通信の別個の確立ごとに、２つのデバイス２００Ａと２００Ｂとの間の通信のセキュリティを検証する必要がある場合の「厳重警戒」モードである。鍵の導出または新たな鍵の導出元となる鍵の記憶は行われない。この厳重警戒モードは、例えば、匿名データまたは機密データの問題がある場合に使用されることになる。この厳重警戒モードは、追加の安全検査を確実にするために、より複雑さを有することになる。また、追加のセキュリティ検査がない修正版「安全」モードもあるが、これは反復回がわずかな場合のＳＡＳを生成し、その後の鍵連続性を信頼する。
この第３の「厳重警戒」モードでは、第２の通常モードのように鍵連続性も使用される。しかし、この第３のモードは、デバイス２００Ａと２００Ｂの両方におけるＳＡＳが等しいことと誤りがなかったこととを保証するために、ＳＡＳの比較による追加の検証を必要とするため、「厳重警戒」である。この第３のモードでは、ＳＡＳを比較するためにすべての反復回ですべての接続についてＭＰＣが使用される。
この第３のモードは、追加の安全検査を保証するために、ネットワークとデバイス２００Ａおよびデバイス２００Ｂにおいてより多くのオーバーヘッドを要することが理解されよう。この第３のモードは、すべての接続において、プロトコルが正常に実行されることと、ＳＡＳが２つの接続デバイスにおいて等しいこととを保証するため、より機密性の高いデータの場合に望ましい。
この第３のモードでは、鍵連続性の概念のみが使用される。
上述のように、本明細書のシステムおよび方法は、図２に示すようなＩｏＴネットワークで使用される。ＩｏＴネットワークにおけるデバイス２００Ａおよび２００Ｂはリソースがわずかしかなく、数種類のシステムがあり、様々な種類のオペレーティング・システムがあり、様々な種類の用途に適応し得ることが想定され得る。これらの想定に基づいて、このシステムおよび方法は以下の特徴を提供する。
使いやすさ。上述のように、従来技術におけるいくつかのセキュリティ保護の提案が存在するが、これらの従来技術のセキュア・プロトコルを適用するためには、多くの手続きが必要であり、従来技術のセキュア・プロトコルの多くは前の鍵の変化を必要とする。セキュリティ保護されていない手段（例えばオープン・インターネットを介した暗号化されていない電子メール）によるセッション鍵の交換は、デバイス間の通信の交換のためのプロセスのセキュリティのすべてを侵害する可能性があることを想起されたい。
本明細書の方法およびシステムは使いやすい。これは、例えばＦｉｒｅｆｏｘ Ｓｙｎｃで実装されているようなＪ−ＰＡＫＥの場合と比較することができる。Ｊ−ＰＡＫＥは、２つのデバイスのプロビジョニングのためにＳＡＳを書き込む必要があるため、より使いにくい。本明細書のシステムおよび方法では、ＳＡＳのプロビジョニングが自動的かつセキュリティ保護されたプロセスであり、このプロセスは（ＳＡＳを比較するＭＰＣとの組み合わせにより）ユーザには透過である。上述のように、図２に示すＩｏＴにおけるデバイス２００Ａおよび２００Ｂは、人間が２つのデバイス２００Ａと２００Ｂのペアリングを行うことができるようにＳＡＳに関する情報を表示することができる画面を備えていないことが多いか、または、少なくともユーザはこの画面と容易に対話することができず、したがってキーボードまたは別のデバイスを備える必要があることがある。
軽量。ＩｏＴネットワークにおけるデバイス２００Ａおよび２００Ｂに存在する限界、すなわち低電力および低処理はよく知られている。これは、ＩｏＴネットワークにおけるＰＫＩの使用を困難にする。本明細書の方法およびシステムは、それぞれ固有の複雑さを伴うＰＫＩ、鍵証明書、信頼モデル、証明機関などを必要とせず、低リソース・デバイスにより適しているため、この問題に対処している。
非集中型。この方法およびシステムは、システムが非集中型であり、もっぱら単一のＣＡのみに依存せず、複数の信頼性のある独立要素を包含するため、ＰＫＩとは異なる。
この方法およびシステムの実装は、２つのライブラリに基づく。すなわち、ＺＲＴＰプロトコルのＣ＋＋実装、つまりＧＮＵ ＺＲＴＰ Ｃ＋＋であるＺＲＴＰＣＰＰ［参照文献１５］と、計算共有、ブール共有、およびＹａｏのガーブル回路に基づくセキュリティ保護された計算方式を効率的に組み合わせ、セキュリティ保護された２パーティ計算における最良実施解決策［参照文献２９］を利用可能にする、ＡＢＹ［参照文献１７］フレームワークである。
ＺＲＴＰＣＰＰ。ライブラリＺＲＴＰＣＰＰが使用される。
ＺＲＴＰＣＰＰライブラリにいくつかの改変が加えられ、いくつかの特徴が追加された。ＭｉｔＭ攻撃を生じさせる可能性のあるＳＡＳの衝突を防止するために、発明人等は暗号鍵サイズ（高度暗号化標準（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ（ＡＥＳ））鍵）を大きくし、それによってより大きなサイズのＳＡＳの新バージョンを作成した。ＳＡＳの衝突は、偶然同じＳＡＳを生成するＭｉｔＭ攻撃が発生した場合、またはＭｉｔＭ攻撃が検出される前に可能なＳＡＳの組み合わせを試すことができる場合に起こり得る。ＳＡＳのサイズを大きくすることにより、通信暗号に関する追加のセキュリティ度が加えられ、また、攻撃者にとってＳＡＳの衝突をより困難にする。意図的でない衝突を生じさせるのが困難であるほど、アルゴリズムの質がよいことが理解されよう。
事前共有モードをサポートするために、ＺＲＴＰＣＰＰライブラリは、デバイス２００Ａ、２００Ｂのいずれかの間のＳＡＳ比較に以前に成功したこと、したがって通信チャネルが正当性確認されたこととを示すＳＡＳ検証済みフラグをサポートするようにも改変された。通常、標準ＺＲＴＰでは、検証済みＳＡＳは若干の複雑さを要し、検証済みＳＡＳを受け入れる追加のインターフェースを加えるための追加の記憶域が必要であるため、検証済みＳＡＳの概念は定義されていない。本明細書の方法およびシステムは、このユーザ・インターフェースの複雑さをなくすＭＰＣの事前追加層を有する。上述のように、ユーザによる手動介入の必要なしに自動的にＳＡＳを比較するためにＭＰＣが使用される［参照文献９］。
この方法およびシステムの両方の用途、すなわちＶｏＩＰまたはＩｏＴにおいて、このレベルで同じ変更が加えられる。しかし、ＩｏＴ用途の場合、ＳＡＳを受け入れるためにインターフェースを維持する必要はなく、一方、ＶｏＩＰ用途の場合は、（ＳＡＳが等しいことと、通信チャネルを介した通話がセキュリティ保護されていることとを確認にするために）ＭＰＣが第１または第２の要素認証として使用され、したがって、ＳＡＳを受け入れるための追加のインターフェースが維持される。
ＡＢＹ。ライブラリＡＢＹは、計算共有と、ブール共有と、Ｙａｏのガーブル回路という３つの異なる秘密共有方式を提供するセキュア計算方式を組み合わせる。これらの秘密共有方式は、例えばデバイス２００Ａと２００Ｂとの間の２パーティ計算をセキュリティ保護された状態にすることができる。ＡＢＹライブラリは、ほとんどすべての暗号演算の事前計算も可能にし、事前計算された紛失通信拡張に基づくセキュア計算方式間の新規な高効率の変換を提供する［参照文献１７］。
このＡＢＹライブラリは、半正直（受動）敵対者のみを考慮する。ＡＢＹライブラリは、プロトコル実行時に２つのデバイス２００Ａと２００Ｂの間の通信中に交換されるメッセージから追加情報を知ろうと試みる計算的に制限された敵対者を想定している。この敵対者はプロトコルから逸脱することができず、したがってＡＢＹは管理者または政府機関による、またはパーティが積極的に不正を行わないと信頼できる場合の、受動的な内部関係者の攻撃に対して保護される。
ＡＢＹライブラリにおけるこの実装形態は、百万長者問題、セキュア計算ＡＥＳ、ユークリッド距離、およびＧｉｔＨｕｂソース・コードに見られるいくつかのその他の用途など、いくつかのサンプル用途がある［参照文献１７］。百万長者問題は、コンピュータ上のローカル・ファイルから得られた入力のための改変を加えて使用した。百万長者問題は、等価性問題に合わせて改変された。
この改変のために、本発明人は、ブール回路クラスにおける以上（ｇｒｅａｔｅｒ ｔｈａｎ ｅｑｕａｌ）関数
＄ｏｕｔ＝ｂｃ−＞ＰｕｔＧＴＧａｔｅ（ｓ＿ａｌｉｃｅ， ｓ＿ｂｏｂ）：＄
のコールの代わりに、
以下の関数により、いわゆる等価問題回路を作成した。
＄ｏｕｔ＝ｂｃ−＞ＰｕｔＥＱＧａｔｅ（ｓ＿ａｌｉｃｅ， ｓ＿ｂｏｂ）；＄
ＺＲＴＰの＄ｓｈｏｗＳＡＳ＄関数内で、この関数にＳＡＳをパラメータによって渡すために関数＄ｔｅｓｔ＿ｅｑｕａｌｉｔｙ＿ｐｒｏｂ＿ｃｉｒｃｕｉｔ＄に新たなパラメータを追加した。このシステムでは、ＭＰＣはＳＡＳを比較し、プロトコルによって交換されるＳＡＳが正しいことを保証する機能のみを有する。
ＺＲＴＰＣＰＰとＡＢＹの両方のための実装と設定に関しては、公開されているプロトコルにいくつかの必要な変更を加える必要がある。ＺＲＴＰプロトコルとＭＰＣプロトコルは両方ともピア・ツー・ピア・シナリオを使用することが知られている。したがって、デバイス２００Ａまたは２００Ｂのうちのいずれがプロセスを開始するか（すなわち送信側であるか）、およびいずれが受信側であるかを定義する必要があった。したがって、ライブラリ間の組み合わせは、ＺＲＴＰＣＰＰの受信側であるデバイス２００Ａまたは２００ＢがＭＰＣのパーティ０となり、他方のデバイス２００Ａまたは２００Ｂ、すなわち送信側がパーティ１であった。これは、単に設計上の問題に過ぎず、本発明を限定するものではない。
ＺＲＴＰＣＰＰライブラリとＡＢＹライブラリの統合は、ｃｍａｋｅプラットフォームを使用して行われた。ＺＲＴＰプロトコルが画面上にＳＡＳディスプレイを作成したとする場合（これは当然ながら本明細書に記載の実装形態では可能ではない）の実行に関しては、このＳＡＳの検証の新たな層が追加された。一方、ＡＢＹフレームワークがＳＡＳの等価性の検証を行うこととなった。
この実施形態では、２つの方式がある。第１の方式は、２つのデバイス２００Ａと２００Ｂの間で交換されたＳＡＳが等しい場合である。この第１の場合、上述のように２つのデバイス２００Ａと２００Ｂの間でデータをセキュリティ保護された状態で秘密裏に交換することができる。第２の場合、比較により、交換されたＳＡＳが異なることがわかる。この方法およびシステムは、２つのデバイス２００Ａと２００Ｂの間のデータまたは情報のいかなる交換もなしに、この試行された通信を中止する。この第２の場合、ＳＡＳが異なる場合は通信においておそらくＭｉｔＭ攻撃があることが想定されることになる。
以下の各段落では、このシステムのセキュリティを分析し、いくつかの知られている攻撃について説明するとともに、これらの攻撃に対するシステムの成功を評価する。この分析は、すべて仮定上の攻撃者の視点から、必要かつ十分なシナリオについて説明する脅威モデルに関して行う。
脅威モデル。ＺＲＴＰは、秘密セッション鍵の値を計算するために使用される対称鍵をキャッシュし、上述のように、これらの計算された値はセッションごとに変化する［参照文献９］。デバイス２００Ａまたは２００Ｂのうちの一方のデバイスのメモリからＺＲＴＰ共有秘密キャッシュを誰かが盗んだ場合、次のセッションのためのセッション鍵を生成することができるため、攻撃者はまさにその次のセッション中にＭｉｔＭ攻撃を開始する唯一の機会を得る。これは、この方法およびシステムにおいて有り得る。上述の「鍵連続性のない」モードは、セッション鍵が新たに生成されるため、この問題を解決することに留意されたい。ＺＲＴＰ共有秘密キャッシュは、新たな各セッションの開始時に常にメモリから削除され、このシステムおよび方法を前述のように常に（ＺＲＴＰディフィー・ヘルマン・モード［参照文献９］に基づく）ＤＨモードで実行する。それにもかかわらず、ＭＰＣによるＳＡＳの比較の必要性は常に存在する。
上述のように、ＳＡＳの衝突が起こる可能性があり、それによってＭｉｔＭが可能になり、すなわち正直なユーザが１つのＳＡＳ鍵を有することができ、攻撃者は同じ鍵を入手または特定することができ、したがってＭｉｔＭにより通話を傍受することができる［参照文献３５を参照］。しかし、この方法において実施され、上述したように、この攻撃は攻撃者が同じＳＡＳ鍵を生成する機会を低減するようにＳＡＳのサイズを大きくすることによって防止することができる。これは、ＺＲＴＰのＲＦＣ［参照文献９］に示されているように、暗号鍵サイズ（ＡＥＳ鍵）を大きくし、したがってより大きなサイズの新たなＳＡＳを作成することによって行われる。ＳＡＳのサイズを大きくすることにより、通信暗号に関してより大きなセキュリティを加え、攻撃者にとってＳＡＳの衝突をより困難にもする。
デバイス２００Ａおよび２００Ｂに記憶されているＭＰＣライブラリでは、認証がまったくないため、敵対者がＭｉｔＭ攻撃を仕掛けることができる。この方法の実行中に交換されたとわかったメッセージから追加情報を知ろうと試みる、計算的に制限された敵対者を想定し、ＡＢＹは半正直（受動）敵対者モデルを使用する。より強力な悪意ある（積極的）敵対者とは異なり、半正直敵対者はプロトコルから逸脱することができない［参照文献２９］。敵対者は悪意ある（積極的）敵対者モデルを調べることができる。積極的攻撃とは、攻撃者がプロトコルの正常な実行を妨害し、変更を加える。攻撃者はネットワークで起こることを「受動的」に単に観察するだけではない。
攻撃シナリオ。本節では、提案の解決策のセキュリティを測定し、攻撃の異なるシナリオに対するこの方法のセキュリティを判定した。このようにして、発明人等は、本明細書で概説されている方法およびシステムのセキュリティを分類することができた。このセキュリティは、認証プロトコルが堅牢であることを実証するためにＡｆｉｆｉ等［参照文献３８］によって使用されたものを改変する１組の定理に基づいていた。評価を完全なものにするために、発明人等は２つの新たな定理も追加した。
想定１。この方法は、非同期化攻撃に対して堅牢である。この証明は以下のことに基づく。固有識別子を使用してデータベース内の当該デバイス２００Ａまたは２００Ｂに関する情報が識別子ファイル２２０に記憶される、非同期化攻撃を回避する方式が図１に示されている。デバイス２００Ａまたは２００Ｂの一方がメッセージを送信するＦ７と、デバイス２００Ａまたは２００Ｂのメモリのローカル・キャッシュに更新が加えられ、次にメモリ内で秘密鍵がローテーションされる。例えば、メモリが情報を破損させた場合、または別の種類の問題が発生した場合、デバイス２００Ａと２００Ｂが両方とも事前共有モードでセッション鍵をネゴシエートすることができなくなる。デバイス２００Ａと２００Ｂの両方が第１の段階に戻って、ステップＦ６およびステップＦ７における新たなＤＨ鍵変更が行われることになる。
想定２。本明細書で概説されている方法およびシステムは、ＰＲＮＧの秘密鍵とローカルに記憶されている秘密鍵との組み合わせによってもたらされるセキュリティに基づき、タグなりすまし攻撃に対して堅牢である。
証明。図１のステップＦ１およびＦ３に示すように、デバイス２００Ａおよびデバイス２００Ｂのそれぞれが固有識別子を持っており、これはＰＲＮＧによって生成されるものである。固有識別子は、任意の他のデバイスとの通信のために使用される。攻撃者がデバイス２００Ａの識別子を入手し、次に攻撃者がデバイス２００Ａになりすましてデバイス２００Ａの識別子をデバイス２００Ｂに送信しようと試みるとする。前述のように、通信セッションのためのセッション鍵を計算するために使用される対称鍵マテリアルをキャッシュするローカル・キャッシュに識別子ファイル２２０があるため、攻撃者はこれを行うことができない。セッション鍵の値はローテーションされ、したがって通信セッションごとに変わることは上述した。したがって、攻撃者がデバイス２００Ａになりすまそうとしても、攻撃者が攻撃の被害者すなわち他方のデバイス２００Ｂとの次の通信セッションのための新たな鍵の生成を試みると、秘密鍵は攻撃者（デバイス２００Ａのなりすまし）のものとは同じではないため、攻撃者がデバイス２００Ｂに発見されないことは不可能であり、したがってデバイス２００Ｂは通信をやめる。最初の反復回で、攻撃者は通信セッションのための認証済みチャネルを有することになるが、通信セッションの正当性確認が失敗するため、攻撃者は攻撃を遂行することができない。
想定３。この方法およびシステムは、再生攻撃に対しても堅牢である。再生攻撃とは、２つのデバイス２００Ａと２００Ｂとの間の１回の通信から情報を入手し、デバイス２００Ａと２００Ｂとの間の次のセッションまたは通信の反復回でその情報を設定しようと試みる攻撃である。例えば、デバイス２００Ａがデバイス２００Ｂとファイルを交換する場合、攻撃者は、その前に交換されたファイルの一部を送信してその通信のためのプロトコルを破損することを試みることができる。この問題を解決するために、この方法および装置は、鍵連続性と前方秘匿性の特性を使用して新たなセッション鍵を生成し、前に交換されたデータおよび暗号化された情報のパケットを陳腐化（すなわち復号不能に）する。これにより、攻撃者がこの種の再生攻撃を行う場合、デバイス２００Ａおよび２００Ｂは送信されたその情報を無視し、進行中の転送を継続するため、この方法は再生攻撃に対して堅牢である。
提案のプロトコルは、後方および前方トレーサビリティ攻撃に対して堅牢である。トレーサビリティは、受動攻撃に分類され得る。このシナリオでは、攻撃者によって行われる唯一の攻撃は、デバイス２００Ａと２００Ｂとの間で交換される情報を盗聴し、その情報の漏洩につながるパターンを把握しようと試みることである。
トレーサビリティ攻撃を克服するようになされた手法は、ローカル情報がデバイス２００Ａまたは２００Ｂに記憶されない前述の厳重警戒モードを使用することである。通信セッションの任意の反復回において、攻撃されたセッションにおける通信方式を再現することを不可能にするＰＲＮＧを使用してすべてのデバイス２００Ａおよび２００Ｂの新たな識別子が生成される。これにより、この方法はトレーサビリティ攻撃に対して堅牢になる。
この方法およびシステムは、単一障害点に対しても抵抗性がある。前述のように、ＰＫＩ実装形態の場合、証明書の正当性を検査する第三者（証明機関（ＣＡ））が存在する。ＣＡは人または組織の公開鍵と識別情報との間にリンクを設定する。したがって、このＰＫＩ実装形態における顧客は第三者に依存する必要がある。いったんＣＡが侵害されるとネットワーク内のすべてのピアも侵害されるため、証明機関は単一障害点に相当する。例えば、Ｌｅｔ’ｓ Ｅｎｃｒｙｐｔ ＣＡは、フィッシングに使用されたサイトに対して１５，２７０通の「ＰａｙＰａｌ」証明書を発行した［参照文献２８］。この種のシステムの障害は、いくつかの実体を侵害する。
本明細書の方法およびシステムは、攻撃に直面しているときでも、デバイス２００Ａおよび２００Ｂの両方ではなく、たかだかデバイス２００Ａまたは２００Ｂの一方を侵害し得るに過ぎない。
ＭｉｔＭはＳＡＳに対する攻撃を利用する。Ｍａｒｔｉｎ Ｐｅｔｒａｓｃｈｅｋ等は、ＤＨのみに対するＭｉｔＭ攻撃について記載しており、ＺＲＴＰでは、最初の接続について必須でありそれ以外は任意である（前方秘匿性を保証するため）音声認識によりＳＡＳを比較することによって認証を行うことができると言っている。しかし、攻撃者はパーティのうちの１人の音声を模倣を試み、それによって他方のパーティをだます可能性がある。この場合、ＭｉｔＭ攻撃者は、２つのデバイス２００Ａと２００Ｂとの間でＲＴＰパケットを単純に転送し、会話を盗聴することができる。最近の研究［参照文献２４］は、この種の攻撃が可能であることを示している。例えば、Ｌｙｒｅｂｉｒｄは、１分間の音声を盗聴するだけで人の音声をクローンする１組のアルゴリズムを有しており、このクローン化はＳＡＳを生成するために使用される可能性がある。
本明細書の手法は、ＭＰＣによるセキュリティの追加の層によってこの問題に対処する。このセキュリティの追加の層は、パーティの入力を秘密裏に保ちながら、パーティの入力にわたる関数を連帯して計算する、パーティすなわちデバイス２００Ａおよび２００Ｂのための方法を作成するという目標を有する。このようにして、他のパーティに何も明らかにせずにＳＡＳの比較を計算することができる。
しかし、識別情報がない場合にＭＰＣでは［参照文献３９から知られるように］ＭｉｔＭ攻撃を防止することができない。この方法では、利用可能な異なる手法がある。攻撃者がＭＰＣ通信を傍受し、同時に、他方のピアのものと等しい交換情報（ＳＡＳ）を生成することができる確率はきわめて低いため、デバイス２００Ａおよび２００Ｂの識別情報は正当なものである必要はない。
これは、本例によって実証することができる。αを、サイズ２６（ラテンアルファベットの文字）のアルファベットα＝｛ａ，ｂ，ｃ，．．．，ｚ｝とし、βを、サイズ１０の数字β＝｛０，１，．．．，９｝であるものとする。γ＝α∪β。
一方のデバイス２００Ｂによって他方のデバイス２００Ａの同じＳＡＳが生成される確率は、式ｎｒによる反復を有する置換によって計算される。ＳＡＳのデフォルト長が４であり、合計文字数（γ＝３６）とすると、ｎ＝γおよびｒ＝４となり、したがってγ４個の可能なケースがある。
この確率を計算すると、攻撃者が他方のデバイスの同じＳＡＳを生成する可能なケースは１つしかない。言い換えると、同じＳＡＳが生成される確率はほぼゼロである。
Figure 2021524944
以下、本明細書で概説されている方法およびシステムとＪ−ＰＡＫＥおよびＺＲＴＰの相違について説明する。それぞれの手法によって使用されるデータの種類（音声かデータか）と、セキュリティ特性である前方秘匿性およびキー連続性も分析することから始めることとする。この方法およびシステムの焦点は、図２に示すＩｏＴネットワークにあるため、これらの手法がこの種の技術に対応しているか、および、自動プロビジョニングとして使用することが可能であるかの確認について述べる。最後に、本明細書のシステムおよび方法はユーザのニーズに応じてセキュリティまたは速度のために適応化された動作モードを有するため、他のプロトコルに複数の動作モードがあるか否かの分析も行う。
自動プロビジョニングは、通信セキュリティをユーザに依存した状態にしておかないため、自動プロビジョニングはＩｏＴネットワークの環境における特徴である。さらに、ＩｏＴネットワークにおけるＩｏＴデバイスの多くはキーボードまたは画面を持たない。１つのエラー源は、人間が、画面に現れるものは何でもプロビジョニングしやすくしがちであることである。人間のユーザは、ＳＡＳが実際に両方のデバイスで一致しているか否か実際に疑問を持たずにＳＡＳを確定する可能性がある。Ｊ−ＰＡＫＥもＺＲＴＰシステムもこのような人間のエラーに対する予防措置を提供しない。
Ｊ−ＰＡＫＥシステムは、デバイスのそれぞれについて、プロビジョニングを行うために画面上に表示される鍵を入力する必要があるため、最低限２つの画面と、キーボードを必要とする。Ｓｙｎｃサービスの一部としてＪ−ＰＡＫＥを使い続けているＰａｌｅ Ｍｏｏｎウェブ・ブラウザを使用して検査を行った。ＺＲＴＰ法では、ＳＡＳを比較し、正当性確認するために音声認識が必要であるため、人間による対話も必要とし、これにはディスプレイと２つのボタンが最低限、必要である。
Ｊ−ＰＡＫＥプロトコルとＺＲＴＰプロトコルは両方とも人間の介入を必要とし、上述のようにＩｏＴネットワークには人間の介在は適切ではないため、両プロトコルは部分的にのみＩｏＴ対応である。
本明細書の以下のセクションでは、ネットワーク・レイテンシに関する提案システムの結果を示す。上述のすべての実装モード、すなわち鍵連続性なし、通常モード、そして最後に厳重警戒モードで実験を行った。鍵連続性があればＭＰＣはすべての反復回で必要でないため、これらのモードは使用法と複雑さの点で異なる。一方、場合によっては、任意の２つのデバイス２００Ａと２００Ｂとの間の通信が確実に常にセキュリティ保護されているようにするために、通信セッションのすべての反復回でＳＡＳを正当性確認することが重要である場合がある。
このシステムおよび方法とＯｐｅｎＳＳＬ ＰＫＩシステムの実行時間も検査した。ＰＫＩシステムでは、上述のように公開鍵証明書に基づいて信頼が築かれる。
システムにおいてネットワークを介したレイテンシを測定した。クロックまたはクロノタイマーを使用して、特定のアクションが完了するのに要する時間を測定する。この場合は、サーバ（受信側）であるデバイスとクライアント（送信側）であるデバイスとの間の通信である。クライアントがサーバにデータを送って応答を待つ場合、全体的な継続期間を測定することができ、これによりクライアントとサーバの間の往復遅延時間（ＲＴＤ）が概算されることになる。目標は、ＰＫＩ方式のシステムと比較した本明細書のシステムおよび方法のプロビジョニング時間を測定することであった。ＭＰＣによる追加遅延とレイテンシ全体に対するその寄与の実際の大きさの程度を算定するために、ＭＰＣを使用した場合としない場合のこのシステムおよび方法の実行時間も測定した。
この実験セクションは３つの部分に分かれる。第１の部分は、実験のためのシステム、すなわち実験に使用されるデバイスの設定および構成とデバイス用のオペレーティング・システムからなる。次に、実装された異なるモードの結果と、結果についての考察を示す。最後に、本明細書のシステムおよび方法の結果とＰＫＩ方式のシステムの結果との比較を開示する。
現実的な環境（低リソース・デバイス）における本システムの使用の結果を測定するために、実験は、ＩｏＴ向けの専用オペレーティング・システムであるカノニカル社のＵｂｕｎｔｕコアを稼働させる２つの一般的な既製のＲａｓｐｂｅｒｒｙ Ｐｉ３モデルＢを使用して行った。
ＩｏＴネットワークは、複数のデバイスの相互接続から生じる。図２に示すような環境を作成した。２つのＲａｓｐｂｅｒｒｙ Ｐｉ Ｂは、ネットワーク２０２（すなわちインターネット）を介して接続されたデバイス２００Ａおよび２００Ｂである。Ｒａｓｐｂｅｒｒｙ Ｐｉの一方２００Ａは、無線ルータ（ＡＳＵＳ ＲＴ−ＡＣ３２００）２０５を介して無線リンク２０４を使用してインターネットに接続され、Ｒａｓｐｂｅｒｒｙ Ｐｉの他方２００Ｂは、無線Ｅｔｈｅｒｎｅｔリンク２０３を使用してインターネット２０２に接続されている。現実的なシナリオにおけるネットワーク・レイテンシのある実行時間を測定するために、インターネット２０２を介してトラフィックをルーティングすることとした。
本明細書の方法を評価するために、３つのモードすべてにおけるプロビジョニング時間を測定した。図３に、プロビジョニング段階を表す評価対象のシナリオを示す。
これらの測定を行うために、図２に示す設定を使用してｇｅｔｔｉｍｅｏｆｄａｙ（）システム・コールを行った。結果を以下の表に示す。表ＩＩＩに示す各モードおよび１から１０までの対応する反復回について、これらの値は、１０回の反復後の平均値および、平均の対応する標準偏差である。
Figure 2021524944
「鍵連続性なし」モードは、前に交換された鍵を記憶する必要がないため、デバイス２００Ａおよび２００Ｂにおける識別子ファイル２００に追加の記憶域を必要としない。この「鍵連続性なし」モードは、すべての反復回において約９８４３ｍｓ±５０．４９の平均時間を要することが判定された。この「鍵連続性なし」モードは、前に交換された鍵にまったく依存せず、鍵連続性を有していないためセキュリティに関するいくつかの利点を有し、必要記憶域も削減する。しかし、実行時間は３種類のモードのうちで最も高い。
「通常」モードは、前記の「鍵連続性なし」モードとは異なり、上述のような鍵連続性の概念を使用する。したがって、通常モードは、デバイス２００Ａおよび２００Ｂにおいて鍵のための追加の記憶域を必要とする。しかし、上記のようにＭＰＣモジュール２１０が（例えば）反復回１０回おきにしか使用されない。この場合、実行時間は、最初の反復回後で２８３ｍｓ±４６．９２である。最初の反復回において、ＭＰＣのオーバーヘッドを考えると、レイテンシは９７４５ｍｓ±５０．４９である。ＭＰＣを反復回１０回おきに使用するため、この結果としてレイテンシ・スパイクが生じる。
「厳重警戒」モードも鍵連続性を利用するため、「厳重警戒」モードは「通常」モードと類似している。しかし、このモードは、反復回のすべてにおいてＭＰＣモジュール２１０によってＳＡＳを常に検証するほどに「厳重警戒」であり、したがって鍵連続性に依存しない。
レイテンシに関しては、「鍵連続性なし」モードと厳重警戒モードとには差がない。通常モードのみが、他の２つのモードと比較した場合に有意に低いレイテンシを有する。この通常モードは反復回１０回おきにＭＰＣモジュール２１０を実行する。他の反復回はすべて類似した挙動を有する。良い点としては、残りの反復回の平均実行時間が２８３±４６．９２ｍｓである。
この通常モードにおける主要な欠点は、デバイス２００Ａおよび２００Ｂにおいて追加の記憶域が必要であることである。記憶域とレイテンシとの暗黙的なトレードオフがある。
要するに、動作モードの選択は、使用されるデバイス２００Ａおよび２００Ｂの種類と、デバイス２００Ａと２００Ｂとの間の通信リンクと、最終的に、ＩｏＴネットワークのユーザの機能要件とに依存する。
認証済みのチャネルを想定しているため、それに付随するオーバーヘッドを表すために実行時間に時間因子δを加えた。しかし、この時間因子δは実行時間の２０％を超える時間に相当すると想定している。
図３に、評価するＰＫＩシナリオを示す。この図３では、ローカルＲａｓｐｂｅｒｒｙ Ｐｉで表されるローカル・クライアントと、ＤｉｇｉＣｅｒｔ証明書がプロビジョニングされたリモートＲａｓｐｂｅｒｒｙ Ｐｉ（図２に示す）においてホストされているサーバ・マシンとが示されている。リモート証明書は、ＣＡと通信するデバイスの複雑さをなくすＯＣＳＰステープリングをサポートする。ＴＬＳサーバは定期的にＯＣＳＰ応答者に自身の証明書の正当性を問い、応答をキャッシュする。ＯＣＳＰ応答者は、証明書を発行したＣＡによって（直接または間接的に）署名されているＯＳＣＰ応答を返す。ＴＬＳクライアントは、このステープリングされたＯＣＳＰ応答を同じように扱うことができ、すなわち、証明書は、有効なタイムスタンプと署名とを有する場合にのみ使用されなければならない。
ＴＬＳハンドシェイク時に、クライアントがサーバに対してＯＣＳＰステープリングのサポートを通知する。それに対して、サーバが証明書状態フラグのサポートを有する場合は、証明書状態フラグを起動する。このプロセスを図３のステップ１に示す。ステップ２において、デバイスＡとＢの間にＳＳＬ接続が確立される。目標は、ＳＳＬ接続ハンドシェイクによって追加されるレイテンシに加えて証明書のＯＣＳＰ（状態）検査レイテンシを測定することである。
このシナリオのレイテンシを測定するために、ＯｐｅｎＳＳＬライブラリのｓ＿ｃｌｉｅｎｔおよびｓ＿ｓｅｒｖｅｒバイナリを使用した。ｓ＿ｓｅｒｖｅｒサービスはサーバ・マシン上で実行され、ｓ＿ｃｌｉｅｎｔはローカル・マシン上で実行された。ＯＣＳＰ情報とサーバ／クライアント・ハンドシェイク結果の両方を得ることができた。１０回の反復にわたって３８０ｍｓ±１１．６０の平均実行時間があることがわかった。
したがって、「通常」モードで稼働する本明細書の方法およびシステムは、ＰＫＩ方式のシステムを使用した結果と比較して２６％のレイテンシ削減を達成する。
本明細書では、音声チャネルがＭＰＣ（ＫＥＡＶ）を介したデータ・ネゴシエーションに置き換えられた修正版セキュア鍵交換プロトコルを利用するＩｏＴネットワークにおけるＩｏＴデバイスのプロビジョニングとＩｏＴデバイス間の軽量通信のための新規な解決策について説明している。セキュリティ検査のレベルおよびオーバーヘッドが次第に高くなる３つの明確に異なる動作モードが定義されている。このＩｏＴネットワークは、複数の固定したセンサに使用可能であるが、自律駆動のためのネットワークにおいても使用可能である。
ＩｏＴ市場において対処しなければならないスケーラビリティと設置面積の小さいデバイスという難しい問題は、「通常」モードをこの環境の解決策として考慮すべきである。この機構は単独で、ＣＰＵまたはバッテリ消費に大きな影響を与えずに小型ＩｏＴデバイスにおけるセキュリティ特性の認証および証明を行うことができる。記憶されるローカル情報を再設計することができ、それによって例えば、これらのモードを最も頻繁に使用される通信方式で使用することができるようにし、他のモードを散発的通信の必要がある場合のために使用することができる。これにより、例えば、古いデバイスを置き換えることになるＩｏＴネットワークを介した新しいシステムの検出を可能にする。
このシステムおよび方法の別の用途では、デバイスはＶｏＩＰデバイスとすることができる。
Ｐａｔｒｉｃｉａ Ｒ．Ｓｏｕｓａ、 Ｊｏａｏ Ｓ．ＲｅｓｅｎｄｅおよびＲｏｌａｎｄｏ Ｍａｒｔｉｎｓの研究は、ポルトガルＦｕｎｄａｃａｏ ｐａｒａ ａ Ｃｉｅｎｃｉａ ｅ Ｔｅｃｎｏｌｏｇｉａ （ＦＣＴ）からの奨学金による支援を受けた（奨学金番号ＳＦＲＨ／ＢＤ／１３５６９６／２０１８、ＰＤ／ＢＤ／１２８１４９／２０１６、ＳＦＲＨ／ＢＰＤ／１１５４０８／２０１６）。
Ｌｕｉｓ Ａｎｔｕｎｅｓのこの研究は、ポルトガル２０２０年パートナーシップ契約に基づき、欧州地域開発基金（ＥＲＤＦ）により、Ｎｏｒｔｈ Ｐｏｒｔｕｇａｌ Ｒｅｇｉｏｎａｌ Ｏｐｅｒａｔｉｏｎａｌ Ｐｒｏｇｒａｍｍｅ（ＮＯＲＴＥ ２０２０）による資金提供を受けたプロジェクト“ＮａｎｏＳＴＩＭＡ：Ｍａｃｒｏ−ｔｏ−Ｎａｎｏ Ｈｕｍａｎ Ｓｅｎｓｉｎｇ：Ｔｏｗａｒｄｓ Ｉｎｔｅｇｒａｔｅｄ Ｍｕｌｔｉｍｏｄａｌ Ｈｅａｌｔｈ Ｍｏｎｉｔｏｒｉｎｇ ａｎｄ Ａｎａｌｙｔｉｃｓ／ＮＯＲＴＥ−０１−０１４５−ＦＥＤＥＲ−００００１６”による支援を受けた。
参照文献
１． Ｙａｎｇ， Ｙｕｃｈｅｎ， ｅｔ ａｌ．“Ａ Ｓｕｒｖｅｙ ｏｎ Ｓｅｃｕｒｉｔｙ ａｎｄ Ｐｒｉｖａｃｙ Ｉｓｓｕｅｓ ｉｎ Ｉｎｔｅｒｎｅｔ−ｏｆ−Ｔｈｉｎｇｓ．”ＩＥＥＥ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ Ｊｏｕｒｎａｌ （２０１７）．
２． Ｈ． Ｓｕｎｄｍａｅｋｅｒ， Ｐ． Ｇｕｉｌｌｅｍｉｎ， Ｐ． Ｆｒｉｅｓｓ ａｎｄ Ｓ． Ｗｏｅｌｆｆｌｅ， “Ｖｉｓｉｏｎ ａｎｄ Ｃｈａｌｌｅｎｇｅｓ ｆｏｒ Ｒｅａｌｉｓｉｎｇ ｔｈｅ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ，”Ｃｌｕｓｔｅｒ ｏｆ Ｅｕｒｏｐｅａｎ Ｒｅｓｅａｒｃｈ Ｐｒｏｊｅｃｔｓ ｏｎ ｔｈｅ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ， ２０１０．
３． Ａｍａｎ， Ｍｕｈａｍｍａｄ， Ｋｅｅ Ｃｈａｉｎｇ Ｃｈｕａ， ａｎｄ Ｂｉｐｌａｂ Ｓｉｋｄａｒ． “Ｍｕｔｕａｌ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｉｎ ＩｏＴ Ｓｙｓｔｅｍｓ ｕｓｉｎｇ Ｐｈｙｓｉｃａｌ Ｕｎｃｌｏｎａｂｌｅ Ｆｕｎｃｔｉｏｎｓ．” ＩＥＥＥ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ Ｊｏｕｒｎａｌ（２０１７）．
４． Ｕｍａｒ，Ａｍｊａｄ． Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｃｕｒｉｔｙ ａｎｄ Ａｕｄｉｔｉｎｇ ｉｎ ｔｈｅ Ｄｉｇｉｔａｌ Ａｇｅ． ｎｇｅ ｓｏｌｕｔｉｏｎｓ， ｉｎｃ， ２００３．
５． Ｈａｏ， Ｆｅｎｇ， ａｎｄ Ｐｅｔｅｒ ＹＡ Ｒｙａｎ． “Ｐａｓｓｗｏｒｄ ａｕｔｈｅｎｔｉｃａｔｅｄ ｋｅｙ ｅｘｃｈａｎｇｅ ｂｙ ｊｕｇｇｌｉｎｇ．” Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋｓｈｏｐ ｏｎ Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌｓ． Ｓｐｒｉｎｇｅｒ Ｂｅｒｌｉｎ Ｈｅｉｄｅｌｂｅｒｇ， ２００８．
６． Ｌａｎｃｒｅｎｏｎ， Ｊｅａｎ， Ｍａｒｊａｎ Å ｋｒｏｂｏｔ， ａｎｄ Ｑｉａｎｇ Ｔａｎｇ． “Ｔｗｏ Ｍｏｒｅ Ｅｆｆｉｃｉｅｎｔ Ｖａｒｉａｎｔｓ ｏｆ ｔｈｅ Ｊ−ＰＡＫＥ Ｐｒｏｔｏｃｏｌ．” Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ａｐｐｌｉｅｄ Ｃｒｙｐｔｏｇｒａｐｈｙ ａｎｄ Ｎｅｔｗｏｒｋ Ｓｅｃｕｒｉｔｙ． Ｓｐｒｉｎｇｅｒ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｐｕｂｌｉｓｈｉｎｇ， ２０１６．
７． Ｈａｏ， Ｆｅｎｇ． “Ｊ−ｐａｋｅ：Ｐａｓｓｗｏｒｄ ａｕｔｈｅｎｔｉｃａｔｅｄ ｋｅｙ ｅｘｃｈａｎｇｅ ｂｙ ｊｕｇｇｌｉｎｇ．”（２０１６）．
８． Ｈａｏ， Ｆｅｎｇ．， Ｅｄ． “Ｓｃｈｎｏｒｒ ＮＩＺＫ Ｐｒｏｏｆ：Ｎｏｎ−ｉｎｔｅｒａｃｔｉｖｅ Ｚｅｒｏ Ｋｎｏｗｌｅｄｇｅ Ｐｒｏｏｆ ｆｏｒ Ｄｉｓｃｒｅｔｅ Ｌｏｇａｒｉｔｈｍ”（２０１３）．
９． Ｚｉｍｍｅｒｍａｎｎ， Ｐｈｉｌ， Ａｌａｎ Ｊｏｈｎｓｔｏｎ， ａｎｄ Ｊｏｎ Ｃａｌｌａｓ． ＺＲＴＰ：Ｍｅｄｉａ ｐａｔｈ ｋｅｙ ａｇｒｅｅｍｅｎｔ ｆｏｒ ｕｎｉｃａｓｔ ｓｅｃｕｒｅ ＲＴＰ． Ｎｏ．ＲＦＣ６１８９．２０１１．
１０． Ｓｅｏ， Ｄｏｎｇ Ｈｗｉ， ａｎｄ Ｐ．Ｓｗｅｅｎｅｙ． “Ｓｉｍｐｌｅ ａｕｔｈｅｎｔｉｃａｔｅｄ ｋｅｙ ａｇｒｅｅｍｅｎｔ ａｌｇｏｒｉｔｈｍ．” Ｅｌｅｃｔｒｏｎｉｃｓ Ｌｅｔｔｅｒｓ ３５．１３（１９９９）：１０７３−１０７４．
１１． Ｇｏｌｄｒｅｉｃｈ， Ｏｄｅｄ． “Ｓｅｃｕｒｅ ｍｕｌｔｉ−ｐａｒｔｙ ｃｏｍｐｕｔａｔｉｏｎ．” Ｍａｎｕｓｃｒｉｐｔ． Ｐｒｅｌｉｍｉｎａｒｙ ｖｅｒｓｉｏｎ（１９９８）：８６−９７．
１２． Ｔｏｏｒａｎｉ， Ｍｏｈｓｅｎ． “Ｓｅｃｕｒｉｔｙ ａｎａｌｙｓｉｓ ｏｆ Ｊ−ＰＡＫＥ．” Ｃｏｍｐｕｔｅｒｓ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ （ＩＳＣＣ）， ２０１４ ＩＥＥＥ Ｓｙｍｐｏｓｉｕｍ ｏｎ． ＩＥＥＥ， ２０１４．
１３． Ｙａｏ， Ａｎｄｒｅｗ Ｃ． “Ｐｒｏｔｏｃｏｌｓ ｆｏｒ ｓｅｃｕｒｅ ｃｏｍｐｕｔａｔｉｏｎｓ．” Ｆｏｕｎｄａｔｉｏｎｓ ｏｆ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ， １９８２． ＳＦＣＳ’０８． ２３ｒｄ Ａｎｎｕａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ． ＩＥＥＥ， １９８２．
１４． Ｈｉｒｔ， Ｍａｒｔｉｎ， Ｕｅｌｉ Ｍａｕｒｅｒ， ａｎｄ Ｂａｒｔｏｓｚ Ｐｒｚｙｄａｔｅｋ． “Ｅｆｆｉｃｉｅｎｔ ｓｅｃｕｒｅ ｍｕｌｔｉ−ｐａｒｔｙ ｃｏｍｐｕｔａｔｉｏｎ．” Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ ｔｈｅ Ｔｈｅｏｒｙ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎ ｏｆ Ｃｒｙｐｔｏｌｏｇｙ ａｎｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｃｕｒｉｔｙ． Ｓｐｒｉｎｇｅｒ Ｂｅｒｌｉｎ Ｈｅｉｄｅｌｂｅｒｇ， ２０００．
１５． Ｃ＋＋ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｏｆ ＺＲＴＰ ｐｒｏｔｏｃｏｌ − ＧＮＵ ＺＲＴＰ Ｃ＋＋ − ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｗｅｒｎｅｒｄ／ＺＲＴＰＣＰＰ ［オンライン、２０１７年３月３０日アクセス］．
１６． Ｐｅｔｒａｓｃｈｅｋ， Ｍａｒｔｉｎ， ｅｔ ａｌ． “Ｓｅｃｕｒｉｔｙ ａｎｄ Ｕｓａｂｉｌｉｔｙ Ａｓｐｅｃｔｓ ｏｆ Ｍａｎ−ｉｎ−ｔｈｅ−Ｍｉｄｄｌｅ Ａｔｔａｃｋｓ ｏｎ ＺＲＴＰ．” Ｊ．ＵＣＳ １４．５（２００８）：６７３−６９２．
１７． ＡＢＹ − Ａ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ｅｆｆｉｃｉｅｎｔ Ｍｉｘｅｄ−ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ Ｔｗｏ−ｐａｒｔｙ Ｃｏｍｐｕｔａｔｉｏｎ ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｅｎｃｒｙｐｔｏｇｒｏｕｐ／ＡＢＹ ［オンライン、２０１７年９月１５日アクセス］．
１８． Ｋｅｌｌｅｒ， Ｍａｒｃｅｌ， Ｅｍｍａｎｕｅｌａ Ｏｒｓｉｎｉ， ａｎｄ Ｐｅｔｅｒ Ｓｃｈｏｌｌ． “ＭＡＳＣＯＴ：ｆａｓｔｅｒ ｍａｌｉｃｉｏｕｓ ａｒｉｔｈｍｅｔｉｃ ｓｅｃｕｒｅ ｃｏｍｐｕｔａｔｉｏｎ ｗｉｔｈ ｏｂｌｉｖｉｏｕｓ ｔｒａｎｓｆｅｒ．” Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２０１６ ＡＣＭ ＳＩＧＳＡＣ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｅｃｕｒｉｔｙ． ＡＣＭ， ２０１６．
１９． Ｈｕａｎｇ， Ｙａｎ， Ｊｏｎａｔｈａｎ Ｋａｔｚ， ａｎｄ Ｄａｖｉｄ Ｅｖａｎｓ． “Ｑｕｉｄ−ｐｒｏ−ｑｕｏ−ｔｏｃｏｌｓ： Ｓｔｒｅｎｇｔｈｅｎｉｎｇ ｓｅｍｉ−ｈｏｎｅｓｔ ｐｒｏｔｏｃｏｌｓ ｗｉｔｈ ｄｕａｌ ｅｘｅｃｕｔｉｏｎ．” Ｓｅｃｕｒｉｔｙ ａｎｄ Ｐｒｉｖａｃｙ（ＳＰ）， ２０１２ ＩＥＥＥ Ｓｙｍｐｏｓｉｕｍ ｏｎ． ＩＥＥＥ， ２０１２．
２０． Ｓａｋａｒｉｎｄｒ， Ｐｉｔｉｐａｔａｎａ， ａｎｄ Ｎｉｒｗａｎ Ａｎｓａｒｉ． “Ｓｅｃｕｒｉｔｙ ｓｅｒｖｉｃｅｓ ｉｎ ｇｒｏｕｐ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｏｖｅｒ ｗｉｒｅｌｅｓｓ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ， ｍｏｂｉｌｅ ａｄ ｈｏｃ， ａｎｄ ｗｉｒｅｌｅｓｓ ｓｅｎｓｏｒ ｎｅｔｗｏｒｋｓ． ”ＩＥＥＥ Ｗｉｒｅｌｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ １４．５ （２００７）．
２１． Ｌａｕｄ， Ｐｅｅｔｅｒ， ａｎｄ Ｌｉｉｎａ Ｋａｍｍ， ｅｄｓ． Ａｐｐｌｉｃａｔｉｏｎｓ ｏｆ Ｓｅｃｕｒｅ Ｍｕｌｔｉｐａｒｔｙ Ｃｏｍｐｕｔａｔｉｏｎ． Ｖｏｌ．１３． ＩＯＳ Ｐｒｅｓｓ， ２０１５．
２２． Ｄｅｖｉｃｅ Ｐａｉｒｉｎｇ Ｕｓｉｎｇ Ｓｈｏｒｔ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｔｒｉｎｇｓ （２０１６） ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｉｄ／ｄｒａｆｔ−ｉｅｔｆ−ｄｎｓｓｄ−ｐａｉｒｉｎｇ−０１．ｈｔｍｌ ［オンライン、２０１７年４月２１日アクセス］
２３．ＴＬＳ Ｈａｎｄｓｈａｋｉｎｇ Ｗｉｔｈ Ｃｅｒｔｉｆｉｃａｔｅｓ ａｎｄ Ｋｅｙｓ（２０１７） ｈｔｔｐｓ：／／ｍｃｕｏｎｅｃｌｉｐｓｅ．ｆｉｌｅｓ．ｗｏｒｄｐｒｅｓｓ．ｃｏｍ／２０１７／０４／ｔｌｓ−ｈａｎｄｓｈａｋｉｎｇ−ｗｉｔｈ−ｃｅｒｔｉｆｉｃａｔｅｓ−ａｎｄ−ｋｅｙｓ．ｐｎｇ ［オンライン、２０１７年４月２５日アクセス］
２４． Ｌｙｒｅｂｉｒｄ ｃｌａｉｍｓ ｉｔ ｃａｎ ｒｅｃｒｅａｔｅ ａｎｙ ｖｏｉｃｅ ｕｓｉｎｇ ｊｕｓｔ ｏｎｅ ｍｉｎｕｔｅ ｏｆ ｓａｍｐｌｅ ａｕｄｉｏ． （２０１７） ｈｔｔｐ：／／ｗｗｗ．ｔｈｅｖｅｒｇｅ．ｃｏｍ／２０１７／４／２４／１５４０６８８２／ａｉ−ｖｏｉｃｅ−ｓｙｎｔｈｅｓｉｓ−ｃｏｐｙ−ｈｕｍａｎ−ｓｐｅｅｃｈ−ｌｙｒｅｂｉｒｄ ［オンライン、２０１７年４月２５日アクセス］
２５． Ｍａｒｔｉｎｉ， Ｓ．： Ｓｅｓｓｉｏｎ Ｋｅｙ Ｒｅｔｒｉｅｖａｌ ｉｎ Ｊ−ＰＡＫＥ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎｓ ｏｆ ＯｐｅｎＳＳＬ ａｎｄ ＯｐｅｎＳＳＨ． （２０１０） ｈｔｔｐ：／／ｓｅｂ．ｄｂｚｔｅａｍ．ｏｒｇ／ｃｒｙｐｔｏ／ｊｐａｋｅ−ｓｅｓｓｉｏｎ−ｋｅｙ−ｒｅｔｒｉｅｖａｌ．ｐｄｆ ［オンライン、２０１７年４月３日アクセス］
２６． Ｔｈｅｒｍｏｓ， Ｐｅｔｅｒ， ａｎｄ Ａｒｉ Ｔａｋａｎｅｎ． Ｓｅｃｕｒｉｎｇ ＶｏＩＰ Ｎｅｔｗｏｒｋｓ。 Ｐｅａｒｓｏｎ Ｅｄｕｃａｔｉｏｎ， ２００７．
２７．Ｃａｎｅｔｔｉ， Ｒａｎ．“Ｏｂｔａｉｎｉｎｇ ｕｎｉｖｅｒｓａｌｌｙ ｃｏｍｐｏｓａｂｌｅ ｓｅｃｕｒｉｔｙ：Ｔｏｗａｒｄｓ ｔｈｅ ｂａｒｅ ｂｏｎｅｓ ｏｆ ｔｒｕｓｔ．” Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ ｔｈｅ Ｔｈｅｏｒｙ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎ ｏｆ Ｃｒｙｐｔｏｌｏｇｙ ａｎｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｃｕｒｉｔｙ． Ｓｐｒｉｎｇｅｒ Ｂｅｒｌｉｎ Ｈｅｉｄｅｌｂｅｒｇ， ２００７．
２８．Ｌｅｔ’ｓ Ｅｎｃｒｙｐｔ ｉｓｓｕｅｓ ｃｅｒｔｓ ｔｏ ’ＰａｙＰａｌ’ ｐｈｉｓｈｉｎｇ ｓｉｔｅｓ：ｈｏｗ ｔｏ ｐｒｏｔｅｃｔ ｙｏｕｒｓｅｌｆ （２０１７） ｈｔｔｐ：／／ｂｉｔ．ｌｙ／２ｉ７Ｚ４ｂＴ ［オンライン、２０１７年５月１９日アクセス］
２９． Ｄｅｍｍｌｅｒ， Ｄａｎｉｅｌ， Ｔｈｏｍａｓ Ｓｃｈｎｅｉｄｅｒ， ａｎｄ Ｍｉｃｈａｅｌ Ｚｏｈｎｅｒ．“ＡＢＹ−Ａ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ｅｆｆｉｃｉｅｎｔ Ｍｉｘｅｄ−Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ Ｔｗｏ−Ｐａｒｔｙ Ｃｏｍｐｕｔａｔｉｏｎ．” ＮＤＳＳ．２０１５．
３０． Ｙａｏ， Ａｎｄｒｅｗ Ｃｈｉ−Ｃｈｉｈ． “Ｈｏｗ ｔｏ ｇｅｎｅｒａｔｅ ａｎｄ ｅｘｃｈａｎｇｅ ｓｅｃｒｅｔｓ．” Ｆｏｕｎｄａｔｉｏｎｓ ｏｆ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ， １９８６．， ２７ｔｈ Ａｎｎｕａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ． ＩＥＥＥ， １９８６．
３１． Ｙａｏ， Ａｎｄｒｅｗ Ｃ． “Ｔｈｅｏｒｙ ａｎｄ ａｐｐｌｉｃａｔｉｏｎ ｏｆ ｔｒａｐｄｏｏｒ ｆｕｎｃｔｉｏｎｓ．” Ｆｏｕｎｄａｔｉｏｎｓ ｏｆ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ， １９８２． ＳＦＣＳ’０８． ２３ｒｄ Ａｎｎｕａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ． ＩＥＥＥ， １９８２．
３２． Ｌｉｎｄｅｌｌ， Ｙｅｈｕｄａ， ａｎｄ Ｂｅｎｎｙ Ｐｉｎｋａｓ． “Ｓｅｃｕｒｅ Ｍｕｌｔｉｐａｒｔｙ ｃｏｍｐｕｔａｔｉｏｎ ｆｏｒ ｐｒｉｖａｃｙ−ｐｒｅｓｅｒｖｉｎｇ ｄａｔａ ｍｉｎｉｎｇ．” Ｊｏｕｒｎａｌ ｏｆ Ｐｒｉｖａｃｙ ａｎｄ Ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ １．１ （２００９）：５．ＡＰＡ
３３． ＭｃＧｒｅｗ， Ｄ．， ｅｔ ａｌ．“ＲＦＣ ３７１１：Ｔｈｅ ｓｅｃｕｒｅ ｒｅａｌ−ｔｉｍｅ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ（ＳＲＴＰ）．” Ｃｉｓｃｏ Ｓｙｓｔｅｍｓ， Ｉｎｃ ａｎｄ Ｅｒｉｃｓｓｏｎ Ｒｅｓｅａｒｃｈ， Ｔｅｃｈ． Ｒｅｐ（２００４）．
３４． Ｚｉｍｍｅｒｍａｎｎ， Ｐ．， Ｊ． Ｃａｌｌａｓ， ａｎｄ Ａ． Ｊｏｈｎｓｔｏｎ． “ＺＲＴＰ： Ｍｅｄｉａ Ｐａｔｈ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ ｆｏｒ Ｕｎｉｃａｓｔ Ｓｅｃｕｒｅ ＲＴＰ（ＲＦＣ６１８９）．”（２０１１）：２０７０−１７２１．
３５． Ｓｉｓａｌｅｍ， Ｄｏｒｇｈａｍ， ｅｔ ａｌ． ＳＩＰ ｓｅｃｕｒｉｔｙ． Ｊｏｈｎ Ｗｉｌｅｙ ＆ Ｓｏｎｓ， ２００９．
３６． Ｈｌａｖａｃｓ， Ｈｅｌｍｕｔ， ｅｔ ａｌ． “Ｅｎｈａｎｃｉｎｇ ＺＲＴＰ ｂｙ ｕｓｉｎｇ Ｃｏｍｐｕｔａｔｉｏｎａｌ Ｐｕｚｚｌｅｓ．” Ｊ．ＵＣＳ １４．５（２００８）：６９３−７１６．
３７． Ｐｅｔｒａｓｃｈｅｋ， Ｍａｒｔｉｎ， ｅｔ ａｌ．“Ｓｅｃｕｒｉｔｙ ａｎｄ Ｕｓａｂｉｌｉｔｙ Ａｓｐｅｃｔｓ ｏｆ Ｍａｎ−ｉｎ−ｔｈｅ−Ｍｉｄｄｌｅ Ａｔｔａｃｋｓ ｏｎ ＺＲＴＰ．” Ｊ．ＵＣＳ １４．５（２００８）：６７３−６９２．
３８． Ａｆｉｆｉ， Ｍ．Ｈ．， ｅｔ ａｌ．“Ｄｙｎａｍｉｃ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｕｓｉｎｇ Ｓｅｌｆ−Ｐｏｗｅｒｅｄ Ｔｉｍｅｒｓ ｆｏｒ Ｐａｓｓｉｖｅ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ．”ＩＥＥＥ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ Ｊｏｕｒｎａｌ（２０１７）．
３９． Ｐａｓｓ， Ｒａｆａｅｌ．“Ｂｏｕｎｄｅｄ−ｃｏｎｃｕｒｒｅｎｔ ｓｅｃｕｒｅ ｍｕｌｔｉ−ｐａｒｔｙ ｃｏｍｐｕｔａｔｉｏｎ ｗｉｔｈ ａ ｄｉｓｈｏｎｅｓｔ ｍａｊｏｒｉｔｙ．” Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ｔｈｉｒｔｙ−ｓｉｘｔｈ ａｎｎｕａｌ ＡＣＭ ｓｙｍｐｏｓｉｕｍ ｏｎ Ｔｈｅｏｒｙ ｏｆ ｃｏｍｐｕｔｉｎｇ． ＡＣＭ， ２００４．

Claims (18)

  1. 第１のデバイス（２００Ａ）と第２のデバイス（２００Ｂ）との間の通信チャネルを介して暗号化メッセージを使用する通信を確立する方法であって、
    前記第１のデバイス（２００Ａ）と前記第２のデバイス（２００Ｂ）とを相互に発見することと、
    前記第１のデバイス（２００Ａ）と前記第２のデバイス（２００Ｂ）との間の前記通信チャネルのための秘密セッション鍵を確立することによって前記通信チャネルの正当性確認をすることと（Ｆ５、Ｆ６、Ｆ７）、
    前記第１のデバイス（２００Ａ）における第１の認証文字列（ＳＡＳ）と前記第２のデバイス（２００Ｂ）における第２の認証文字列（ＳＡ）とを計算することと、
    計算された前記第１のＳＡＳを前記第１のデバイス（２００Ａ）の第１のＭＰＣモジュール（２１０Ａ）に、計算された前記第２のＳＡＳを前記第２のデバイス（２００Ｂ）の第２のＭＰＣモジュール（２０１Ｂ）に挿入し、前記第２のデバイス（２００Ｂ）の前記第２のＭＰＣモジュール（２１０Ｂ）における前記第１のＳＡＳと、前記第１のデバイス（２００Ａ）の前記第１のＭＰＣモジュール（２０１Ａ）における第２のＳＡＳとを評価することによって前記通信チャネルのセキュリティを確認することと、
    前記通信チャネルの前記セキュリティの前記確認がなされた場合に、交換された前記秘密セッション鍵を使用して前記第１のデバイス（２００Ａ）と前記第２のデバイス（２００Ｂ）との間に共有秘密を確立することと、
    前記通信チャネルを介して前記暗号化されたメッセージを交換することとを含む、方法。
  2. 前記相互の発見は、前記第１のデバイス（２００Ａ）と前記第２のデバイス（２００Ｂ）との間の識別子を提供することを含む、請求項１に記載の方法。
  3. 前記第１のデバイス（２００Ａ）と前記第２のデバイス（２００Ｂ）との間の識別子を提供することは、前記第１のデバイス（２００Ａ）と前記第２のデバイス（２００Ｂ）との間で開始メッセージおよび肯定応答メッセージを交換すること（Ｆ１、Ｆ２、Ｆ３、Ｆ４）を含み、前記開始メッセージおよび前記肯定応答メッセージは前記識別子を含む、請求項２に記載の方法。
  4. 前記識別子は、前記第１のデバイス（２００Ａ）と前記第２のデバイス（２００Ｂ）とのうちの少なくとも一方の乱数識別情報を生成することによって提供される、請求項２または３に記載の方法。
  5. 前記識別子の提供は、サーバから前記第１のデバイス（２００Ａ）と前記第２のデバイス（２００Ｂ）の識別子を受信することを含む、請求項２に記載の方法。
  6. 前記正当性確認（Ｆ５、Ｆ６、Ｆ７）は、前記第１のデバイス（２００Ａ）から前記第２のデバイス（２００Ｂ）への第１の鍵交換と、前記第２のデバイス（２００Ｂ）から前記第１のデバイス（２００Ａ）への第２の鍵交換とを含む、請求項１から５のいずれか一項に記載の方法。
  7. 交換された前記メッセージの比較の成功後に、前記第１のデバイス（２００Ａ）から前記第２のデバイス（２００Ｂ）に確認メッセージを送信し、前記第２のデバイス（２００Ｂ）から前記第１のデバイス（２００Ａ）に確認メッセージを送信することをさらに含む、請求項１から６のいずれか一項に記載の方法。
  8. 前記第１の鍵交換における第１の秘密鍵が前の第１の秘密鍵から生成され、前記第２の鍵交換における第２の秘密鍵が前の第２の秘密鍵から生成される、請求項７に記載の方法。
  9. 前記通信チャネルの前記正当性確認は、前記通信チャネルを介したすべてのメッセージの交換前に実施される、請求項１から８のいずれか一項に記載の方法。
  10. 前記通信チャネルの前記正当性確認は、前記通信チャネルを介したいくつかのメッセージの交換後にのみ実施される、請求項１から９のいずれか一項に記載の方法。
  11. 前記第１のデバイス（２００Ａ）と前記第２のデバイス（２００Ｂ）との前記相互発見は、直接通信またはサーバの使用のうちの一方により前記第１のデバイス（２００Ａ）と前記第２のデバイス（２００Ｂ）との間のメッセージの自動交換によって実施される、請求項１から１０のいずれか一項に記載の方法。
  12. 移動車両上のＩｏＴデバイスを含む複数のＩｏＴデバイス、または複数のＶｏＩＰデバイスを含む、ネットワークにおける、請求項１から１１のうちのいずれか一項に記載の方法の使用。
  13. 複数のデバイス（２００Ａ、２００Ｂ）を含むネットワークであって、前記複数のデバイス（２００Ａ、２００Ｂ）は、
    通信チャネル（２０２、２０３、２０４）を介して前記複数のデバイス（２００Ａ、２００Ｂ）のうちの他のデバイスのうちの１つまたは複数のデバイスにメッセージを送信するための送信器（２４０）と、
    前記複数のデバイス（２００Ａ、２００Ｂ）のうちの他のデバイスのうちの１つまたは複数のデバイスから前記通信チャネル（２０２、２０３、２０４）よりメッセージを受信するための受信器（２３０）と、
    セッション鍵を記憶するための識別子ファイル（２２０）と、
    前記複数のデバイス（２００Ａ、２００Ｂ）のうちの１つのデバイスから通信チャネル（２０２、２０３、２４）を介して認証文字列（ＳＡＳ）を受信し、前記通信チャネル（２０２、２０３、２０４）のセキュリティを確認するマルチパーティ計算モジュール（２１０）と、
    前記セッション鍵を使用して前記通信チャネル（２０２、２０３、２０４）との間でのメッセージを暗号化および復号するための通信モジュール（２２０）とを含む、ネットワーク。
  14. 前記マルチパーティ計算モジュール（２１０）は、第１の認証文字列を有し、前記複数のデバイス（２００Ａ、２００Ｂ）のうちの他のデバイスのうちの１つから第２の認証文字列を受信し、それによって前記通信チャネル（２０２、２０３、２０４）の前記セキュリティを確認するように適合されている、請求項１３に記載のネットワーク。
  15. 前記デバイス（２００Ａ、２００Ｂ）は、複数のセッション鍵を記憶するためのストレージをさらに含む、請求項１３または１４に記載のネットワーク。
  16. 前記デバイス（２００Ａ、２００Ｂ）は、前記デバイス（２００Ａ、２００Ｂ）を識別する識別子を生成するための擬似乱数生成器をさらに含む、請求項１３から１５のうちのいずれか一項に記載のネットワーク。
  17. 前記デバイス（２００Ａ、２００Ｂ）に前記デバイス（２００Ａ、２００Ｂ）のうちの他の１つのデバイスの識別子を提供するためのサーバをさらに含む、請求項１３から１６のうちのいずれか一項に記載のネットワーク。
  18. 前記複数のデバイス（２００Ａ、２００Ｂ）は、ＩｏＴネットワーク、自律的車両ネットワークにおけるデバイス、またはＶｏＩデバイスである、請求項１３から１７のうちのいずれか一項に記載のネットワーク。
JP2021514484A 2018-05-16 2019-05-16 マルチパーティ計算（ｍｐｃ）による物のインターネット・セキュリティ Pending JP2021524944A (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
PT11074118 2018-05-16
PT20181000034529 2018-05-16
EP18174412.9 2018-05-25
EP18174412.9A EP3570575A1 (en) 2018-05-16 2018-05-25 Internet of things security with multi-party computation (mpc)
PCT/EP2019/062713 WO2019219862A1 (en) 2018-05-16 2019-05-16 Internet of things security with multi-party computation (mpc)

Publications (1)

Publication Number Publication Date
JP2021524944A true JP2021524944A (ja) 2021-09-16

Family

ID=62620623

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021514484A Pending JP2021524944A (ja) 2018-05-16 2019-05-16 マルチパーティ計算（ｍｐｃ）による物のインターネット・セキュリティ

Country Status (5)

Country Link
US (2) US20210203492A1 (ja)
EP (2) EP3570575A1 (ja)
JP (1) JP2021524944A (ja)
CN (1) CN112425136B (ja)
WO (1) WO2019219862A1 (ja)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10601823B2 (en) * 2015-04-07 2020-03-24 Tyco Fire & Security Gmbh Machine to-machine and machine to cloud end-to-end authentication and security
CN109255247B (zh) * 2018-08-14 2020-08-14 阿里巴巴集团控股有限公司 多方安全计算方法及装置、电子设备
CN114124423B (zh) * 2020-08-31 2023-04-07 Oppo广东移动通信有限公司 一种认证方法、客户端、服务端及存储介质
US20220078184A1 (en) * 2020-09-09 2022-03-10 University Of Florida Research Foundation, Incorporated Method, apparatus, and computer program product for secure two-factor authentication
CN112989368B (zh) * 2021-02-07 2022-05-17 支付宝(杭州)信息技术有限公司 多方联合进行隐私数据处理的方法及装置
CN112800479B (zh) * 2021-04-07 2021-07-06 支付宝(杭州)信息技术有限公司 利用可信第三方的多方联合数据处理方法及装置
CN113177212B (zh) * 2021-04-25 2022-07-19 支付宝(杭州)信息技术有限公司 联合预测方法和装置
CN113612821A (zh) * 2021-07-14 2021-11-05 支付宝(杭州)信息技术有限公司 多方安全计算中的数据交互方法和装置
CN114553397B (zh) * 2022-02-14 2024-04-12 山东大学 一种国密sm4分组密码算法的加密优化方法及装置
CN114697113A (zh) * 2022-03-30 2022-07-01 医渡云（北京）技术有限公司 一种基于硬件加速卡的多方隐私计算方法、装置及系统

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000354031A (ja) * 1999-04-06 2000-12-19 Mitsubishi Electric Corp 共通鍵共有方法
JP2004529595A (ja) * 2001-06-08 2004-09-24 ノキア コーポレイション データ伝送のセキュリティを確保する方法、通信システム及び通信装置
JP2005099980A (ja) * 2003-09-24 2005-04-14 Nippon Telegr & Teleph Corp <Ntt> サービス提供方法、サービス提供プログラム、ホスト装置、および、サービス提供装置
JP2005354556A (ja) * 2004-06-14 2005-12-22 Matsushita Electric Ind Co Ltd 鍵交換装置、鍵交換システム、鍵交換方法、および暗号通信システム
JP2006332903A (ja) * 2005-05-24 2006-12-07 Ntt Docomo Inc 鍵取得機器、鍵提供機器、鍵交換システム及び鍵交換方法
US20070157026A1 (en) * 2005-07-27 2007-07-05 Zimmermann Philip R Method and system for key management in voice over internet protocol
US20090158039A1 (en) * 2007-11-09 2009-06-18 Ramnath Prasad Device pairing using "human-comparable" synchronized audible and/or visual patterns

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2384403B (en) * 2002-01-17 2004-04-28 Toshiba Res Europ Ltd Data transmission links
US7646872B2 (en) * 2004-04-02 2010-01-12 Research In Motion Limited Systems and methods to securely generate shared keys
US9350708B2 (en) * 2010-06-01 2016-05-24 Good Technology Corporation System and method for providing secured access to services
US9467425B2 (en) * 2013-03-18 2016-10-11 Intel Corporation Key refresh between trusted units
US9112840B2 (en) * 2013-07-17 2015-08-18 Avaya Inc. Verifying privacy of web real-time communications (WebRTC) media channels via corresponding WebRTC data channels, and related methods, systems, and computer-readable media
US20150288667A1 (en) * 2014-04-08 2015-10-08 Samsung Electronics Co., Ltd. Apparatus for sharing a session key between devices and method thereof
US9621547B2 (en) * 2014-12-22 2017-04-11 Mcafee, Inc. Trust establishment between a trusted execution environment and peripheral devices
US20170230383A1 (en) * 2016-02-10 2017-08-10 Silent Circle, SA Inter-communication unit message routing and verification of connections

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000354031A (ja) * 1999-04-06 2000-12-19 Mitsubishi Electric Corp 共通鍵共有方法
JP2004529595A (ja) * 2001-06-08 2004-09-24 ノキア コーポレイション データ伝送のセキュリティを確保する方法、通信システム及び通信装置
JP2005099980A (ja) * 2003-09-24 2005-04-14 Nippon Telegr & Teleph Corp <Ntt> サービス提供方法、サービス提供プログラム、ホスト装置、および、サービス提供装置
JP2005354556A (ja) * 2004-06-14 2005-12-22 Matsushita Electric Ind Co Ltd 鍵交換装置、鍵交換システム、鍵交換方法、および暗号通信システム
JP2006332903A (ja) * 2005-05-24 2006-12-07 Ntt Docomo Inc 鍵取得機器、鍵提供機器、鍵交換システム及び鍵交換方法
US20070157026A1 (en) * 2005-07-27 2007-07-05 Zimmermann Philip R Method and system for key management in voice over internet protocol
US20090158039A1 (en) * 2007-11-09 2009-06-18 Ramnath Prasad Device pairing using "human-comparable" synchronized audible and/or visual patterns

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
BRESCIANI, R.: "The ZRTP Protocol Analysis on the Diffie-Hellman Mode", COMPUTER SCIENCE DEPARTMENT TECHNICAL REPORT, vol. TCD-CS-2009-13, JPN6023022729, 12 June 2009 (2009-06-12), pages 1 - 21, ISSN: 0005077361 *
HOEPMAN, JAAP-HENK, THE EPHEMERAL PAIRING PROBLEM, vol. arXiv:0802.0834v1, JPN6023022730, 6 February 2008 (2008-02-06), pages 1 - 15, ISSN: 0005077360 *
PASINI, S. AND VAUDENAY, S.: "SAS-Based Authenticated Key Agreement", PUBLIC KEY CRYPTOGRAPHY - PKC 2006, vol. 3958, JPN6023022727, 2006, pages 395 - 409, XP047030188, ISSN: 0005077363, DOI: 10.1007/11745853_26 *
ZIMMERMANN, P.: "ZRTP: Media Path Key Agreement for Unicast Secure RTP", REQUEST FOR COMMENTS: 6189, JPN6023022728, April 2011 (2011-04-01), pages 1 - 115, XP015075963, ISSN: 0005077362 *
齋藤 恒和: "認証鍵交換プロトコルＺＲＴＰの盗聴確率の評価", 2016 SYMPOSIUM ON CRYPTOGRAPHY AND INFORMATION SEURITY, JPN6023022726, 19 January 2016 (2016-01-19), JP, pages 1 - 7, ISSN: 0005077364 *

Also Published As

Publication number Publication date
US20210203492A1 (en) 2021-07-01
CN112425136B (zh) 2023-10-10
EP3570575A1 (en) 2019-11-20
CN112425136A (zh) 2021-02-26
EP3794856A1 (en) 2021-03-24
WO2019219862A1 (en) 2019-11-21
US20230155816A1 (en) 2023-05-18

Similar Documents

Publication Publication Date Title
CN112425136B (zh) 采用多方计算(mpc)的物联网安全性
CN108599925B (zh) 一种基于量子通信网络的改进型aka身份认证系统和方法
KR101343248B1 (ko) 교환 세션의 총체적 보안
CN102164033B (zh) 防止服务被攻击的方法、设备及系统
Chattaraj et al. A new two-server authentication and key agreement protocol for accessing secure cloud services
US20140164768A1 (en) Detecting matched cloud infrastructure connections for secure off-channel secret generation
Gaba et al. Robust and lightweight mutual authentication scheme in distributed smart environments
US8683194B2 (en) Method and devices for secure communications in a telecommunications network
US9787651B2 (en) Method and device for establishing session keys
CN110635901B (zh) 用于物联网设备的本地蓝牙动态认证方法和系统
Nikooghadam et al. A secure and robust elliptic curve cryptography‐based mutual authentication scheme for session initiation protocol
CN110493367B (zh) 无地址的IPv6非公开服务器、客户机与通信方法
CN108599926B (zh) 一种基于对称密钥池的HTTP-Digest改进型AKA身份认证系统和方法
Sureshkumar et al. A robust mutual authentication scheme for session initiation protocol with key establishment
Kfoury et al. Secure End-to-End VoIP System Based on Ethereum Blockchain.
Peeters et al. SMS OTP security (SOS) hardening SMS-based two factor authentication
Jander et al. Practical Defense-in-depth Solution for Microservice Systems.
Aiash A formal analysis of authentication protocols for mobile devices in next generation networks
KR20210126319A (ko) 키 관리 장치 및 방법
Jurcut et al. Design requirements to counter parallel session attacks in security protocols
Krasnowski et al. Introducing a Verified Authenticated Key Exchange Protocol over Voice Channels for Secure Voice Communication.
Shehada et al. Performance evaluation of a lightweight iot authentication protocol
Hsu et al. SGD 2: Secure Group-based Device-to-Device Communications with Fine-grained Access Control for IoT in 5G
Gurbani et al. A secure and lightweight scheme for media keying in the session initiation protocol (SIP) work in progress
Alshahrani et al. Anonymous IoT mutual inter-device authentication scheme based on incremental counter (AIMIA-IC)

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201117

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210728

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220407

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230428

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230606

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20230905

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20231106

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231206

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20240306