JP2010507928A - Secure telemetric link - Google Patents

Secure telemetric link Download PDF

Info

Publication number
JP2010507928A
JP2010507928A JP2009525689A JP2009525689A JP2010507928A JP 2010507928 A JP2010507928 A JP 2010507928A JP 2009525689 A JP2009525689 A JP 2009525689A JP 2009525689 A JP2009525689 A JP 2009525689A JP 2010507928 A JP2010507928 A JP 2010507928A
Authority
JP
Japan
Prior art keywords
node
communication
key
message
network
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
JP2009525689A
Other languages
Japanese (ja)
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.)
Medtronic Inc
Original Assignee
Medtronic Inc
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
Priority claimed from US11/828,867 external-priority patent/US7930543B2/en
Priority claimed from US11/828,886 external-priority patent/US7940933B2/en
Priority claimed from US11/828,940 external-priority patent/US8102999B2/en
Application filed by Medtronic Inc filed Critical Medtronic Inc
Publication of JP2010507928A publication Critical patent/JP2010507928A/en
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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/0002—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network
    • A61B5/0015—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network characterised by features of the telemetry system
    • A61B5/0024—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network characterised by features of the telemetry system for multiple sensor units attached to the patient, e.g. using a body or personal area network
    • 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/12—Applying verification of the received information
    • 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • 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
    • H04L9/0844—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 with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61N—ELECTROTHERAPY; MAGNETOTHERAPY; RADIATION THERAPY; ULTRASOUND THERAPY
    • A61N1/00—Electrotherapy; Circuits therefor
    • A61N1/18—Applying electric currents by contact electrodes
    • A61N1/32—Applying electric currents by contact electrodes alternating or intermittent currents
    • A61N1/36—Applying electric currents by contact electrodes alternating or intermittent currents for stimulation
    • A61N1/372—Arrangements in connection with the implantation of stimulators
    • A61N1/37211—Means for communicating with stimulators
    • A61N1/37252—Details of algorithms or data aspects of communication system, e.g. handshaking, transmitting specific data or segmenting data
    • A61N1/37282—Details of algorithms or data aspects of communication system, e.g. handshaking, transmitting specific data or segmenting data characterised by communication with experts in remote locations using a network
    • 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/80—Wireless
    • 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/88—Medical equipments

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Power Engineering (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Medical Informatics (AREA)
  • Public Health (AREA)
  • Biomedical Technology (AREA)
  • Molecular Biology (AREA)
  • Surgery (AREA)
  • Animal Behavior & Ethology (AREA)
  • General Health & Medical Sciences (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Veterinary Medicine (AREA)
  • Pathology (AREA)
  • Biophysics (AREA)
  • Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)

Abstract

通信プロトコルを使用して、データプライバシー、メッセージの完全性、メッセージの新しさ、及びユーザ認証を、特に、ボディエリアネットワークの埋め込み可能医療デバイスへのテレメトリックトラフィック、及び、ボディエリアネットワークの埋め込み可能医療デバイスからのテレメトリックトラフィックに提供する。暗号化、メッセージの完全性、及びメッセージの新しさは、デバイス識別番号及び疑似乱数から導出されたトークンのようなノンス及びエフェメラルセッションキーの使用を通じて提供される。
【選択図】図１Using communication protocols, data privacy, message integrity, message freshness, and user authentication, especially telemetric traffic to body area network implantable medical devices, and body area network implantable healthcare Provide telemetric traffic from the device. Encryption, message integrity, and message freshness are provided through the use of nonce and ephemeral session keys such as tokens derived from device identification numbers and pseudo-random numbers.
[Selection] Figure 1

Description

本発明は、データ通信設定においてセキュア通信を提供することに関し、特に、埋め込み可能医療デバイスと外部デバイス管理ハードウェアとの間のテレメトリーにおけるセキュリティ、埋め込み可能医療デバイスと他の埋め込み可能医療デバイスとの間のテレメトリーにおけるセキュリティ、及び外部医療デバイスと他の外部医療デバイスとの間のテレメトリーにおけるセキュリティの提供においてセキュアな通信を提供することに関する。   The present invention relates to providing secure communication in a data communication setting, in particular, security in telemetry between an implantable medical device and external device management hardware, between an implantable medical device and other implantable medical devices. And providing secure communications in providing security in telemetry between external medical devices and other external medical devices.

埋め込み可能医療デバイス（「ＩＭＤ」）に関する技術の改良、特に、電力貯蔵、保全、及び小型化の分野におけるＩＭＤに関する技術の改良によって、現代の埋め込み可能医療デバイスには無線電気通信機能を装備することが可能になっている。このような通信の利益には、たとえばバッテリー寿命の残量、発生した治療イベント数、又は特定の患者の健康データといった情報を送信するようにＩＭＤに要求する能力、及び、治療法、治療頻度等を変更する命令をデバイスへ送信する能力が含まれる。これらの通信のすべては、患者の健康及び治療成果を最大にするすべての関係者側の必要性によって動機付けられており、この成功の判断基準の一環として、ＩＭＤを患者から除去しなければならない状況又は患者に関する何らかの侵襲的な処置が必要となる状況を回避するという要望によっても後押しされている。何らかの外科的又は侵襲的な処置に伴う危険に付随するものは、適用可能な標準治療（standard of care）に従ってこのような処置が行われるとき、このような処置に関連付けられるコストである。   Modern implantable medical devices should be equipped with wireless telecommunications capabilities through improvements in technology related to implantable medical devices ("IMDs"), particularly in the field of power storage, maintenance, and miniaturization. Is possible. Such communication benefits include, for example, the ability to request the IMD to send information such as remaining battery life, number of treatment events that occurred, or health data for a particular patient, and treatment method, treatment frequency, etc. The ability to send an instruction to change the device to the device is included. All of these communications are motivated by the needs of all parties to maximize patient health and treatment outcomes, and as part of this success criterion, the IMD must be removed from the patient It is also driven by the desire to avoid situations or situations that require some invasive treatment on the patient. Associated with the risks associated with any surgical or invasive procedure is the cost associated with such procedure when such procedure is performed in accordance with applicable standard of care.

ＩＭＤを患者内に残している間、ＩＭＤと通信する利益を利用する際に、無線通信が、理想的には適しており、現在まで、ＩＭＤがその埋め込まれた状態にある間にＩＭＤと情報を定期的に交換する唯一の実用的な方法である。したがって、通信が、ＩＭＤ若しくは管理デバイスへ又はＩＭＤ若しくは管理デバイスから送信されているか否かにかかわらず、さらに、（たとえば、更新された命令がＩＭＤへ送信されることとは対照的に）測定値が送信されているか否かにかかわらず、ＩＭＤ管理のために電気通信を使用することには、ＩＭＤへの通信及びＩＭＤからの通信、或いは、体外（すなわち、埋め込まれていない）ＩＭＤ管理デバイス間の通信（本明細書では、交互に「テレメトリー」と総称する）が含まれ得る。   Wireless communication is ideally suited to take advantage of the benefits of communicating with the IMD while leaving the IMD in the patient, and until now, the IMD and information while the IMD is in its implanted state. Is the only practical way to replace it regularly. Thus, regardless of whether a communication is being sent to or from the IMD or management device, further measurements (eg, as opposed to an updated command being sent to the IMD). Regardless of whether or not is transmitted, using telecommunications for IMD management includes communication to and from the IMD, or between an IMD management device outside the body (ie, not implanted) Communication (collectively referred to herein as “telemetry” alternately).

テレメトリー、特にＩＭＤテレメトリーは、病状又は他の健康状態の治療をより便利且つ効果的にすることができるが、テレメトリーを使用することによって、第三者がこのようなデバイスの管理に干渉できないように保証することが重要である。たとえば、盗聴のみであっても、たとえば医療保険のプライバシー及び説明責任に関する法律（「ＨＩＰＡＡ」）といった特定のデータプライバシー制度のもとで保護され得る患者データを危険にさらすおそれがある。さらに危ういことには、管理デバイスから医療デバイスへのテレメトリー通信が干渉を受ける場合、意図されていた重要な療法が、埋め込みデバイスをホスティング（hosting）している患者に対して施されないおそれがあり、その結果、おそらく、治療効果は準最適なものになる。悪意のある第三者が、通信をインターセプトして、その通信を、デバイスへの偽の命令に置き換えた場合、又は、正当な命令であってもそれを繰り返して、正しくない療法若しくは過度の療法を埋め込み物に施させた場合には、埋め込み物のホストに対して悪影響を与えるおそれがある。   Telemetry, especially IMD telemetry, can make the treatment of medical conditions or other health conditions more convenient and effective, but using telemetry prevents third parties from interfering with the management of such devices. It is important to guarantee. For example, eavesdropping alone can endanger patient data that can be protected under certain data privacy schemes, such as the Health Insurance Privacy and Accountability Act ("HIPAA"). Even more dangerous, if the telemetry communication from the management device to the medical device is interfered, the intended critical therapy may not be given to the patient hosting the implant device, As a result, the therapeutic effect is probably suboptimal. If a malicious third party intercepts the communication and replaces it with a fake command to the device, or repeats even a legitimate command, incorrect or excessive therapy When is applied to the embedded material, there is a risk of adversely affecting the host of the embedded material.

現在まで、ＩＭＤテレメトリーの用途に適したほとんどの一般的な無線通信プロトコルは、方向性を有するプロトコルではなく、「ブロードキャスト」のプロトコルである。したがって、ＩＭＤがテレメトリー信号の範囲内にある（又は、通信がＩＭＤから開始されたときは、受信デバイスがＩＭＤの範囲内にある）場合、その信号へのアクセスが介護人及び／又は患者によって意図されたものであろうとなかろうと、その信号の範囲内にあるいずれの受信デバイスも、その信号にアクセスできると一般に想定することができる。   To date, most common wireless communication protocols suitable for IMD telemetry applications are “broadcast” protocols, not directional protocols. Thus, if the IMD is within the telemetry signal (or the receiving device is within the IMD when communication is initiated from the IMD), access to the signal is intended by the caregiver and / or patient. It can generally be assumed that any receiving device within the range of the signal, whether done or not, can access the signal.

ＩＭＤを伴う多くのテレメトリートランザクションの距離範囲が短いことによって、或る程度、或る種の物理レイヤ認証は達成されている。換言すれば、認可されていない関係者が送信デバイスの非常に近くにいなければならないことから、盗聴者（又は盗聴者のツール）の物理的な存在は、このような情報を正当に送信又は受信する関係者に視覚的にはっきりと見えることになるので、ＩＭＤに関係する通信へのほとんどの不正アクセスは実現不可能である。しかしながら、テレメトリーの適用の範囲は絶えず拡大しており、或る段階で、たとえば、患者が医師待合室に腰掛けている間、対象とする受信デバイスが完全に別の部屋にあっても、ＩＭＤにインターロゲートすることが考えられ得る。ＩＭＤと外部ハードウェアとの間の通信に必要な距離が大きくなるにつれて、侵入者又は盗聴者が、通信信号の受信、通信信号への干渉、さらには通信信号の操作を行う機会も多くなる。   To some extent, some physical layer authentication has been achieved due to the short distance range of many telemetry transactions involving IMD. In other words, the physical presence of an eavesdropper (or an eavesdropper's tool) can legitimately transmit such information, as unauthorized parties must be very close to the sending device. Most unauthorized access to communications related to IMD is not feasible, as it will be clearly visible to the receiving parties. However, the scope of telemetry applications is constantly expanding, and at some stage, for example, while a patient is sitting in a doctor's waiting room, even if the intended receiving device is in a completely separate room, the IMD is interfacing. It can be considered to rogate. As the distance required for communication between the IMD and external hardware increases, there are more opportunities for an intruder or eavesdropper to receive the communication signal, interfere with the communication signal, and further manipulate the communication signal.

また、メッセージが「新鮮」であることも重要である。すなわち、メッセージが、近時において一度しか送信されていないことも重要である。たとえば、療法が適用されているにもかかわらず、患者の生理的状態の変化がないことを偽って示す診断センサからのデータの複製通信の結果、療法が過度になるか、又は付帯リスクを有する他の不要な医療介入が行われるおそれがある。メッセージプライバシー（すなわち、暗号化）に加えて、真のデータセキュリティには、メッセージの完全性及びメッセージの新しさ（message freshness）の双方も必要とされる。３つのすべてがなければ、悪意のある第三者によって悪用されるおそれのある隙間が存在するか、又はさらには、悪意がなくてもエラーを許容するおそれのある隙間が存在する。もちろん、このような悪用が起こり得るか否かは、特に設計の立場から関連はない。テレメトリーのセキュリティは、検討されているインターセプトのシナリオから生じる問題の実際の可能性に関係なく、あらゆる盗聴又はインターセプトを防止するように保証されるべきである。   It is also important that the message is “fresh”. That is, it is also important that the message has been sent only once recently. For example, the therapy may be excessive or have an attendant risk as a result of replicated communication of data from a diagnostic sensor that falsely indicates that the patient's physiological state has not changed despite the application of the therapy Other unnecessary medical interventions may occur. In addition to message privacy (ie, encryption), true data security requires both message integrity and message freshness. Without all three, there are gaps that can be misused by malicious third parties, or even gaps that can tolerate errors without being malicious. Of course, whether such abuse can occur is not particularly relevant from a design standpoint. Telemetry security should be ensured to prevent any eavesdropping or interception, regardless of the actual likelihood of problems arising from the intercept scenario being considered.

テレメトリーセキュリティに対するこれまでの手法は、たとえば、サーバベースの認証及びストレージを伴っていた。このように、永久的なキー情報が、機器上に記憶されることはなかった。しかしながら、この手法では、２４時間利用可能なサーバへのセキュアな通信チャネルが必要とされる。また、この手法では、臨床医は、ボディエリアネットワーク（ＢＡＮ）デバイス又はノードを管理するよりも前に、サーバシステムに対して認証を受ける必要がある。   Previous approaches to telemetry security have involved, for example, server-based authentication and storage. In this way, permanent key information has never been stored on the device. However, this approach requires a secure communication channel to the server that is available 24 hours a day. This approach also requires the clinician to authenticate to the server system before managing the body area network (BAN) device or node.

代替的に、バイオメトリックトークン（キーフォブ（key fob）等）が、ＩＭＤサポート機器をＩＭＤに対して認証するのに使用されてきた。しかしながら、この手法によって認証キー（バイオメトリックキー及びＩＭＤキーの双方）が喪失されやすく、トークンも、ＩＭＤ管理を行うために提示する患者によって忘れられる可能性があり、これによって、不都合なことに、ケアの延期が必要となりがちである。パスワードによって増強されたトークンも、同様に、喪失されやすく、ノンコンプライアンス（トークンを予約に持ってこない、又は、認証情報を忘れる）を受けやすく、同様に、喪失又は盗難にあった場合に、危険にさらされやすかった。   Alternatively, biometric tokens (such as key fob) have been used to authenticate IMD support devices to the IMD. However, this approach is prone to loss of authentication keys (both biometric keys and IMD keys), and tokens can also be forgotten by the patient presenting for IMD management, which unfortunately causes It is often necessary to postpone care. Tokens augmented with passwords are also susceptible to loss and non-compliance (do not bring the token to the reservation or forget the authentication information), and are similarly dangerous if lost or stolen. It was easy to be exposed to.

本発明は、特にＩＭＤ及び他の医療デバイスの管理に良く適したテレメトリー通信のセキュアシステムを提供する。ＩＭＤへの通信及びＩＭＤからの通信、並びに、外部デバイスへの通信及び外部デバイスからの通信を保護するシステムが提供される。このシステムは、通信ノードへの通信及び通信ノードからの通信、特にＩＭＤへの通信及びＩＭＤからの通信が正当なものであることを保証するために、１つ又は複数の認証方法と共に、暗号化のシステムを実施する。特定の実施の形態では、たとえば、データ暗号化及びキー管理の厳格な手法によって、正当性が保証され、好ましくは、認証は、認証カード又はトークンを保持することに加えて、少なくとも１つのモダリティを使用してセキュアにされる。   The present invention provides a secure system for telemetry communications that is particularly well suited for managing IMD and other medical devices. A system is provided that protects communications to and from the IMD, as well as communications to and from external devices. The system is encrypted with one or more authentication methods to ensure that communication to and from the communication node, particularly communication to and from the IMD, is legitimate. Implement the system. In certain embodiments, legitimacy is ensured, for example, by rigorous methods of data encryption and key management, and preferably, authentication includes at least one modality in addition to holding an authentication card or token. Use to be secure.

特定の実施の形態では、本発明は、近接性に依存した「バックドア」を提供する。当該バックドアは、特定の患者の医療デバイスのネットワーク内のノード間又はモジュール間の通信を可能にするのに通常必要とされる認証情報なしで任意のＩＭＤへのアクセス及びその管理を可能にすることができる。医療デバイスのネットワークは、「ボディエリアネットワーク」又は「ＢＡＮ」と呼ばれる。また、本発明は、いくつかの実施の形態では、認証が、認証情報を実際に送信する（もちろん、認証情報が危険にさらされやすくなるおそれがある）ことなく実行されるという点で、厳密認証、すなわち、同一性のゼロ知識証明も提供する。   In certain embodiments, the present invention provides a “back door” that relies on proximity. The backdoor allows access to and management of any IMD without the authentication information normally required to allow communication between nodes or modules within a network of a particular patient medical device. be able to. A network of medical devices is called a “body area network” or “BAN”. The present invention is also strict in that, in some embodiments, authentication is performed without actually transmitting the authentication information (of course, the authentication information is likely to be compromised). It also provides authentication, ie zero knowledge proof of identity.

患者及び認可された介護人に反する興味又は動機を有する、認可されていない第三者は、盗聴者の素性、ロケーション、又は動機にかかわらず、本明細書では、「攻撃者」と総称される。攻撃者は、通信を実際に混乱させることなく単に盗聴することを望む場合もあるし、場合によっては患者に関する保護されている健康情報を取得することを望む場合もあるし、ＢＡＮノード製造者に独自のＢＡＮノードの振る舞いの態様を知りたい場合もある。これらの目的のために、本発明の実施の形態は、暗号の使用を通じてメッセージプライバシー（すなわち、暗号化）を提供する。   Unauthorized third parties with interests or motivations contrary to the patient and authorized caregivers are collectively referred to herein as “attackers” regardless of the eavesdropper's identity, location, or motive. . An attacker may simply want to eavesdrop without actually disrupting the communication, or in some cases may wish to obtain protected health information about the patient, and Sometimes you want to know the behavior of your own BAN node. For these purposes, embodiments of the present invention provide message privacy (ie, encryption) through the use of cryptography.

十分な電気通信能力及び計算能力を有する攻撃者は、ＢＡＮのノード間のすべての通信をインターセプトして制御し、ＢＡＮのノード間のメッセージの削除、変更、複製、又は別の変更のいずれかを行うことができる場合があることも考えられ得る。本発明の実施の形態は、たとえばＩＭＤへの命令及びＩＭＤによって診断ノードに提供される情報が正当なものであることを保証するメッセージ認証プロトコルの使用を通じて、メッセージの完全性（すなわち、メッセージ認証）を提供する。同様に、新しく生成されたセッションキー及びトークンベースのシステムを通じて、又は、本発明の代替的な実施の形態ではタイムスタンプの使用を通じて、メッセージの新しさを保証することもできる。本発明は、特定の実施の形態では、メッセージの完全性（送信されたメッセージが、それらのメッセージが対象とする受信者によって、変更されていない状態で受信される）及びメッセージの新しさ（メッセージが、タイムリーに受信され、且つ、攻撃者によって送信された、前に送信されたメッセージのコピーではない）という補助的な要請に基づいて、メッセージが、秘密キーを有しない者からセキュアに維持されることを可能にする。   An attacker with sufficient telecommunications and computing capabilities intercepts and controls all communications between the BAN nodes and either deletes, modifies, duplicates, or otherwise modifies messages between the BAN nodes. It can also be considered that there may be cases where it can be done. Embodiments of the present invention provide message integrity (ie, message authentication), eg, through the use of a message authentication protocol that ensures that the instructions to the IMD and the information provided by the IMD to the diagnostic node are legitimate. I will provide a. Similarly, message freshness can be guaranteed through newly generated session key and token-based systems, or through the use of time stamps in alternative embodiments of the present invention. The present invention, in certain embodiments, provides message integrity (messages sent are received unchanged by the intended recipients) and message freshness (messages). Message is secured from a person who does not have a private key based on the supplementary request that it is received in a timely manner and is not a copy of a previously sent message sent by the attacker Allows to be done.

本発明の実施の形態によって与えられる保護にもかかわらず、通信の保護は、好ましくは、最適な患者ケアという全体的な原則によって動機づけられ、且つ、必要な場合には、その全体的な原則を補助する。したがって、本発明の特定の実施の形態は、特定の緊急事態又は他の強制的な状況において、健康への不利な影響を防ぐために、緊急事態介護人がデバイスに対して自身を認証する時間又は証明書を有するか否かにかかわらず、この実施態様の特定のセキュリティの機能を迂回するデバイスに対して、「バックドア」によるデバイスとの通信を許可することができる。   Despite the protection afforded by the embodiments of the present invention, communication protection is preferably motivated by the overall principle of optimal patient care and, if necessary, that overall principle. To assist. Thus, certain embodiments of the present invention provide a time or time for an emergency caregiver to authenticate himself to the device in order to prevent adverse health effects in certain emergencies or other compulsory situations. Regardless of having a certificate, devices that bypass the specific security features of this embodiment can be allowed to communicate with the device via a “backdoor”.

本発明の実施の形態によるセキュリティメカニズム及びプロトコルは、セキュリティサービスがセットアップされて、通信デバイスのうちの少なくとも１つに関して（迂回されるのではなく）有効にされていることを必要とし、ブロック暗号の一実施態様の使用をさらに必要とする場合がある。他の実施の形態では、本発明を実施するＢＡＮのすべての通信デバイスは、同一のボディエリアネットワークキーＫＢＡＮを共有し、新しい各テレメトリーセッションの開始時に新しいセッションキーＫｓｅｓを協同して生成する。最初に、このようなデバイス識別情報交換が、通信セッションをオープンするために必要とされるセキュアにされていない交換を介して行われる。着信するパケット及び発信するパケットの双方のパケット長は、好ましくは、セッションの継続時間の間固定され、指定された長さに合致しないパケットは、好ましくは、ネットワークの物理レイヤにおいて拒絶される。 Security mechanisms and protocols according to embodiments of the present invention require that security services be set up and enabled (rather than bypassed) for at least one of the communication devices, and block ciphers There may be a further need to use one embodiment. In another embodiment, all communication devices of the BAN implementing the present invention share the same body area network key K BAN and collaboratively generate a new session key K ses at the start of each new telemetry session. . Initially, such device identification information exchange takes place via an unsecured exchange required to open a communication session. The packet length of both incoming and outgoing packets is preferably fixed for the duration of the session, and packets that do not match the specified length are preferably rejected at the physical layer of the network.

本発明の実施形態によるボディエリアネットワークの一般的なネットワークトポロジを示す図である。1 is a diagram illustrating a general network topology of a body area network according to an embodiment of the present invention. FIG. 本発明の実施形態によるネットワークノード間のネットワークキーのセキュアな送信のプロトコルを示す図である。FIG. 3 is a diagram illustrating a protocol for secure transmission of a network key between network nodes according to an embodiment of the present invention. ネットワークキー送信プロトコルの一代替的な実施形態を示す図である。FIG. 6 illustrates an alternative embodiment of a network key transmission protocol. 本発明の一実施形態による２つの体外デバイスを有するボディエリアネットワークのトポグラフィを示す図である。FIG. 4 shows a topography of a body area network having two extracorporeal devices according to one embodiment of the present invention. 本発明によるネットワークキー伝播プロトコルの一代替的な実施形態を示す図である。FIG. 6 illustrates an alternative embodiment of a network key propagation protocol according to the present invention. 本発明の特定の実施形態による疑似乱数ジェネレータの機能のデータフロー図である。FIG. 6 is a data flow diagram of the functionality of a pseudo-random number generator according to a particular embodiment of the invention. 本発明の特定の実施形態による疑似乱数ジェネレータの機能のデータフロー図である。FIG. 6 is a data flow diagram of the functionality of a pseudo-random number generator according to a particular embodiment of the invention. 本発明の特定の実施形態による疑似乱数ジェネレータの機能のデータフロー図である。FIG. 6 is a data flow diagram of the functionality of a pseudo-random number generator according to a particular embodiment of the invention. 本発明の特定の実施形態による疑似乱数ジェネレータの機能のデータフロー図である。FIG. 6 is a data flow diagram of the functionality of a pseudo-random number generator according to a particular embodiment of the invention. 本発明の実施形態によるセッションキーの生成のデータフロー図である。FIG. 4 is a data flow diagram of session key generation according to an embodiment of the present invention. 本発明の実施形態によるメッセージのＣＴＲモードの暗号化及び解読のデータフローを示す図である。FIG. 6 is a diagram illustrating a data flow of CTR mode encryption and decryption of a message according to an embodiment of the present invention. 本発明の実施形態によるノンスレジスタのデータ構造を示す図である。It is a figure which shows the data structure of the nonce register by embodiment of this invention. 本発明の一実施形態によるテレメトリーパケットのデータ構造を示す図である。It is a figure which shows the data structure of the telemetry packet by one Embodiment of this invention. 本発明の一実施形態によるメッセージの暗号化／解読及び認証のデータフローを示す図である。FIG. 6 illustrates a data flow of message encryption / decryption and authentication according to an embodiment of the present invention. 本発明の一実施形態による概略的なハードウェアアーキテクチャを示す図である。FIG. 2 illustrates a schematic hardware architecture according to an embodiment of the present invention. 本発明の一実施形態の緊急事態アクセスプロトコルのネットワークトポグラフィを示す図である。FIG. 3 is a diagram illustrating a network topography of an emergency access protocol according to an embodiment of the present invention. 本発明の一実施形態による緊急事態アクセスプロトコルの疑似プロトコル及びデータフローを示す図である。FIG. 6 illustrates a pseudo protocol and data flow of an emergency access protocol according to an embodiment of the present invention. セキュアにされたウェイクアップパケットのグラフィカル表現を示す図である。FIG. 6 shows a graphical representation of a secured wakeup packet. セキュアにされたウェイクアップパケットのＭＡＣの生成を示すブロック図である。FIG. 5 is a block diagram illustrating MAC generation of a secured wakeup packet. セキュアにされたウェイクアップパケットを送受信するプロセスのフローチャートである。FIG. 6 is a flowchart of a process for transmitting and receiving a secured wakeup packet. セキュアにされたウェイクアップパケットを送受信するプロセスのフローチャートである。FIG. 6 is a flowchart of a process for transmitting and receiving a secured wakeup packet.

本発明による無線ネットワークの一セキュリティ実施様態の実施形態は、さまざまな層のセキュリティ又はさまざまな度合いの多要素認証を実施することができる。本明細書で検討されるこれらのセキュリティの層は、たとえば、通常、入出力ファシリティ（たとえば、ポート）、１つ又は複数の中央処理装置（チップ等）、及び複数のメモリロケーションを有するスマートカード、すなわち小さなプラスチックカード又はフォブによって実施することができる。スマートカード技術は、「ユーザが有する物（something the user has）」レベルのセキュリティとして、単独で機能することによるか、又は、たとえば「ユーザが知っている物（something the user knows）」（すなわち、パスワード）若しくは「ユーザである物（something the user is）」（すなわち、ユーザに関連付けられたバイオメトリックパラメータ）と結び付けられた多要素認証のコンポーネントとして機能することによるかのいずれかで、セキュリティを実施するのに使用することができる。本発明に従って実施されるようなカードは、好ましくは、時に「プロセッサカード」又は「マイクロプロセッサ多機能カード」と呼ばれるタイプのメモリ、少なくとも１つのプロセッサ、及びデータ処理機能を有する。これらのカードは、好ましくは、国際標準化機構の、電気接点を有する集積回路カード（Integrated Circuit Cards with Electrical Contact）の標準規格ＩＳＯ７８１６で指定されたタイプのものとすることができ、この仮定は、本明細書の代表的な実施形態に関してなされる。特定の実施形態では、特定の患者認証は、スマートカードデバイスを介して管理されるが、しかしながら、ＩＭＤのデバイスキーは、好ましくは、暗号化されていない形ではスマートカード上に記憶されない。   Embodiments of one security implementation of a wireless network according to the present invention can implement various layers of security or varying degrees of multi-factor authentication. These security layers discussed herein include, for example, a smart card that typically has input / output facilities (eg, ports), one or more central processing units (chips, etc.), and multiple memory locations, That is, it can be implemented with a small plastic card or fob. Smart card technology works by acting alone as a “something the user has” level of security, or for example, “something the user knows” (ie, Enforce security, either by acting as a multi-factor authentication component associated with a password) or “something the user is” (ie, a biometric parameter associated with the user) Can be used to do. A card as implemented in accordance with the present invention preferably has a type of memory, sometimes referred to as a “processor card” or “microprocessor multifunction card”, at least one processor, and data processing functions. These cards may preferably be of the type specified in the International Standards Organization's standard ISO 7816 for Integrated Circuit Cards with Electrical Contacts. It is made with respect to representative embodiments of the specification. In certain embodiments, specific patient authentication is managed via a smart card device, however, the device key of the IMD is preferably not stored on the smart card in an unencrypted form.

本発明のいくつかの実施形態は、本明細書で、テレメトリー通信のタイムライン、すなわち、テレメトリー通信の「新しさ」として知られているものの確証を提供する。たとえば、一度正当に規制することができる治療法（therapeutic modality）は、悪意のある第三者によって繰り返し可能なものであってはならない。第三者が、単なる暗号化のみに基づいた通信を盗聴できる場合、その第三者は、その命令を反復して繰り返すことができる。悪意のある第三者が、たとえＩＭＤへのメッセージの内容を知らない場合であっても、第三者は、このメッセージを繰り返すことが患者のためにならないことを合理的に予測することができる。第三者は、十分な試行錯誤によって、メッセージの内容を完全に無視してでも危険な影響を実施するおそれがある。したがって、本発明の実施形態は、メッセージの新しさを保証してこのような攻撃を防止するシステムも達成する。本明細書では、「暗号化された」及び「セキュアにされた」という用語は、一般に同義ではないことが理解されよう。暗号化されたメッセージは、プライバシー（すなわち、機密性）のみが保証されているメッセージである。セキュアにされたメッセージは、プライバシー、完全性、新しさ、及び同一性が保証されているメッセージである。この後者の概念は、ユーザ認証（メッセージが、それを明らかに送信した人（又はノード）から実際に来たものである）及びメッセージ認証（メッセージが、送信者によって送信された形態を有し、且つ、正当な送信者によって意図された時刻にのみに送信されたものであり、それ以外の時に送信されていないもの）の双方の認証の概念を組み込んでいる。   Some embodiments of the present invention provide confirmation of what is known herein as a telemetry communication timeline, ie, “newness” of telemetry communication. For example, a therapeutic modality that can be legitimately regulated once should not be repeatable by a malicious third party. If a third party can eavesdrop on communications based solely on encryption, the third party can repeat the command repeatedly. Even if a malicious third party does not know the content of the message to the IMD, the third party can reasonably predict that repeating this message will not be for the patient. . A third party may carry out dangerous effects even if the message content is completely ignored by sufficient trial and error. Accordingly, embodiments of the present invention also achieve a system that guarantees message freshness and prevents such attacks. It will be understood herein that the terms “encrypted” and “secured” are generally not synonymous. An encrypted message is a message for which only privacy (ie confidentiality) is guaranteed. A secured message is a message that guarantees privacy, integrity, freshness, and identity. This latter concept has the form of user authentication (the message is actually from the person (or node) who clearly sent it) and message authentication (the message was sent by the sender, In addition, both authentication concepts are incorporated, which are transmitted only at a time intended by a legitimate sender and not transmitted at any other time.

本明細書では、通信を送信又は受信するノード（すなわち、医療デバイスの文脈では、埋め込まれたデバイス若しくは外部のデバイス、センサ、プログラマ、モニタ、又はＢＡＮ内の他の器具）を暗号学の慣習に従って「アリス（Alice）」又は「ボブ（Bob）」と呼ぶ場合がある。デバイスのユーザ又は患者について明示的に述べていない限り（たとえば、アリスの患者又は「ホスト」、すなわち、アリスデバイスを埋め込まれている患者）、アリス又はボブはデバイス又はノードを指す。また、特定の実施形態では、スマートカードが、信頼される第三者認証局に通常関連付けられているいくつかの機能を実行でき、カードの保持者による（たとえば、保持者のパスワード及びバイオメトリック認証による）認証時に、カードが、システム内の信頼される関係者とみなされ、カードの保持者のＩＭＤに対応するＩＭＤキーを保持するという点で、スマートカード（スマートカードリーダ／ライタに挿入されている時のスマートカードを含む）という用語を使用する。システムの認可されたアドミニストレータ又はユーザがメッセージの送信又は受信を可能にすることを意図していない第三者（又は、このような人物の制御下にあるデバイス）は、一般に、「攻撃者」と呼ばれる。また、暗号学と一致して、ビット単位の排他的論理和演算（すなわち、ビット単位のモジュロ２加算）については、シンボル   As used herein, nodes that send or receive communications (ie, in the context of medical devices, embedded devices or external devices, sensors, programmers, monitors, or other instruments in the BAN) follow cryptographic conventions. Sometimes referred to as “Alice” or “Bob”. Unless explicitly stated about the user or patient of the device (eg, Alice's patient or “host”, ie, the patient who has implanted the Alice device), Alice or Bob refers to the device or node. Also, in certain embodiments, a smart card can perform several functions typically associated with a trusted third party certificate authority, such as by the card holder (eg, the holder's password and biometric authentication). Upon authentication, the card is considered to be a trusted party in the system and holds an IMD key corresponding to the card holder's IMD, inserted into a smart card (smart card reader / writer). (Including smart cards). Third parties (or devices under the control of such persons) that are not intended to allow authorized administrators or users of the system to send or receive messages are generally referred to as “attackers”. be called. Consistent with cryptography, the bitwise exclusive OR operation (ie, bitwise modulo-2 addition)

Figure 2010507928
又は「ＸＯＲ」を使用し、連結については、シンボル｜又は‖を使用する。本明細書ではしばしば、ソフトウェア又はハードウェアが、感覚のあるエージェントであることを示唆しているように思われるよう、特定のソフトウェアプロセス又はハードウェアコンポーネントは、特定の情報を「知っている」、「要求する」、「予測する」、若しくは「送信する」、又は、特定の機能若しくはアクティビティを実行する（たとえば「計算する」）として説明される。このような擬人化した言及は、問題となっているハードウェア又はソフトウェアが意識、動機、又は知性（人工的又はそれ以外）を有することを示すか又は暗に意味することを意図するものではなく、これらの表現は、一般に、人間であろうが、又は他のハードウェア若しくはソフトウェアのプロセス若しくはコンポーネントであろうが、それによってプログラミング又は命令された通りにソフトウェア又はハードウェアが自動的に挙動することを示すのに使用されることが、当業者には理解されよう。たとえば、特定の値を「予測する」と言われるソフトウェアプロセスは、規則に従わない引数がエラーハンドリングコードによって処理される、特定の変数タイプ又は値であるように指定された引数を有するソフトウェア関数を指す場合がある。
Figure 2010507928
 Alternatively, use “XOR” and use the symbol | or ‖ for concatenation. Often herein, a particular software process or hardware component “knows” certain information, as it seems to suggest that the software or hardware is a sensible agent, It is described as “requesting”, “predicting”, or “sending”, or performing a particular function or activity (eg, “calculating”). Such anthropomorphic references are not intended to indicate or imply that the hardware or software in question has consciousness, motivation, or intelligence (artificial or otherwise). These representations, generally human beings or other hardware or software processes or components, that cause software or hardware to behave automatically as programmed or commanded It will be appreciated by those skilled in the art that For example, a software process that is said to "predict" a particular value may have a software function with an argument specified to be a particular variable type or value, where an argument that does not follow the rules is handled by the error handling code. May point.

図１は、本発明の実施形態によるボディエリアネットワークのトポグラフィを示している。プログラマ「ボブ」１１０及びＩＭＤ「アリス」１１５から成る一例示のボディエリアネットワーク（ＢＡＮ）１００が示されている。これらの２つのノード、アリス及びボブは、非セキュアチャネル１２０を介して非セキュアテレメトリーセッション１１７をすでに確立している。プログラマ１１０は、認証デバイス１３０との（たとえば、有線接続１２５を介した）セキュア通信用に接続されている。認証デバイス１３０は、ここでは、バイオメトリック入力窓１３５を有するスマートカードリーダ／ライタである。これらの実施形態によれば、本明細書でより十分に説明するように、各場合において、患者によって携行されてＩＭＤ管理で使用されるスマートカードに基づき、セキュリティの増大する順に、以下の情報を認証データとして使用することができる。   FIG. 1 shows a topography of a body area network according to an embodiment of the present invention. An exemplary body area network (BAN) 100 comprising a programmer “Bob” 110 and an IMD “Alice” 115 is shown. These two nodes, Alice and Bob, have already established a non-secure telemetry session 117 via the non-secure channel 120. The programmer 110 is connected for secure communication with the authentication device 130 (eg, via a wired connection 125). The authentication device 130 is here a smart card reader / writer with a biometric input window 135. According to these embodiments, as described more fully herein, in each case, based on smart cards carried by the patient and used for IMD management, the following information is in order of increasing security: Can be used as authentication data.

本発明の典型的な実施形態では、最低でも、デバイスの患者（又は、適用可能な場合には、他の認可されたアドミニストレータ）が、ＫｄｅｖＡ（デバイス１１５用のキー）、ＩＤＡ（デバイス１１５用の識別番号）として注記される情報を含むスマートカード１４０（患者が有する物）を提示する。さらなるセキュリティは、患者のスマートカード１４０にパスワードＫＰＷ１５０を加えたもの、すなわち、本明細書でＥ（ＫｄｅｖＡ；ＫＰＷ）、ＩＤＡとして注記されるものを使用することによって提供することができる。パスワードＫＰＷ１５０（患者が有する物であり、且つ、患者が知っている物）も、スマートカード素子１４５上に記憶されている。Ｅ（ＫｄｅｖＡ；ＫＰＷ）は、すなわち、デバイスキーＫｄｅｖＡがパスワードＫＰＷ（すなわち「パスワードキー」）によって暗号化されたものである。ここで、Ｅ（ｘ；ｙ）は、キー「ｙ」を使用して「ｘ」をセキュアにするのに使用される暗号化の関数を示し、別の言い方をすれば、特定の暗号文＝Ｅ（平文；キー）を示す。特定の実施形態では、ユーザの認証は、患者のスマートカード１４０又は非電子的な情報カードに、パスワードＫＰＷ１５０を加え、バイオメトリックスキャンＫｂｉｏ、すなわち「バイオメトリックキー」１５５（患者が有する物であり、知っている物であり、且つ、患者である物）を加えたもの、すなわち、本明細書でＥ（Ｅ（ＫｄｅｖＡ；ＫＰＷ）；ＫｂｉО）、ＩＤＡとして注記されるもの、によって実行される。 In an exemplary embodiment of the invention, at a minimum, the device patient (or other authorized administrator, if applicable) is assigned to K devA (key for device 115), ID A (device 115). Present the smart card 140 (the patient has) with the information noted as the identification number. Further security may be provided by using the patient's smart card 140 plus the password K PW 150, ie, what is noted herein as E (K devA ; K PW ), ID A. it can. Password K PW 150 (the patient has and is known to the patient) is also stored on smart card element 145. E (K devA ; K PW ) is the device key K devA encrypted with the password K PW (ie, “password key”). Where E (x; y) denotes the encryption function used to secure “x” using the key “y”, in other words, a specific ciphertext = E (plain text; key). In a particular embodiment, the user authentication is performed by adding a password K PW 150 to the patient's smart card 140 or non-electronic information card, and biometric scan K bio , or “biometric key” 155 (what the patient has. , Know, and patient), ie, E (E (K devA ; K PW ); K bio )), ID A in this specification , Executed by.

図１に示すように、アリスの患者（図示せず）には、スマートカードデバイス１４０が提供されている。スマートカードデバイス１４０は、メモリ、ファームウェア、ローカルストレージ、及び／又は組み合わせ素子１４５を含む。アリスの患者は、スマートカード１４０をパスワード１５０及び患者のバイオメトリック特徴で初期化している。患者のバイオメトリック特徴は、ここでは、指紋１５５である。   As shown in FIG. 1, Alice's patient (not shown) is provided with a smart card device 140. Smart card device 140 includes memory, firmware, local storage, and / or combinational element 145. Alice's patient has initialized smart card 140 with password 150 and patient biometric features. The biometric feature of the patient is here a fingerprint 155.

本発明の特定の実施形態では、スマートカード１４０、又は、スマートカードリーダ１３０若しくはオンボードプログラマノード１１０に取って代わる或るインターフェースとインターフェースするＵＳＢ／Ｆｉｒｅｗｉｒｅ（登録商標）キーフォブを利用して、本明細書のセキュリティ方式の態様を実施することができる。特定の実施形態では、このようなスマートカード又はキーフォブは、すでに実施され且つスマートカード１４０又はキーフォブに実装された、特定の暗号及びメッセージ認証コード（ＭＡＣ）、たとえばチップハードウェアに実施された暗号及びメッセージ認証コード（ＭＡＣ）、又は代替的に、ＲＯＭ又はフラッシュメモリに記憶されている暗号及びメッセージ認証コード（ＭＡＣ）を有し、これらは、スマートカード又はキーフォブ上の素子１４５として抽象的に示されている。   Certain embodiments of the present invention utilize a USB / Firewire® key fob that interfaces with a smart card 140 or an interface that replaces the smart card reader 130 or on-board programmer node 110. A security scheme aspect of the document can be implemented. In certain embodiments, such a smart card or key fob is a specific cipher and message authentication code (MAC) that has already been implemented and implemented in the smart card 140 or key fob, such as a cipher implemented on chip hardware and It has a message authentication code (MAC), or alternatively encryption and message authentication code (MAC) stored in ROM or flash memory, which are abstractly shown as element 145 on the smart card or key fob. ing.

ＩＭＤを含むＢＡＮをセットアップ又は初期化して、上述したプロトコルに従ってＢＡＮキーを伝播するときに、まず、患者は、自身のＩＭＤの認証マテリアル（たとえば、スマートカード１４０）をブリッジデバイス１１０に提供する。このスマートカード１４０は、たとえば、ＩＭＤ１１５と共に発行する（且つ、術後に患者に与える）こともできるし、前もって存在する患者のスマートカードデバイス１４０上に必要な情報を入力することもできる。特定の実施形態では、患者は、自身のスマートカード１４０を（ここでは、インターフェースデバイス１３０を介して）ブリッジデバイス１１０内に挿入した後、自身のパーソナルパスワードＫｐｗ１５０をブリッジデバイス１１０内に入力するように促され（プログラマ１１０に実装されて存在するＧＵＩを介して、又は、適切な別個のインターフェースを介して、理想的には、患者自身のパーソナルメモリから入力される）、さらに、指紋１５５又は網膜スキャン等、患者の一意のバイオメトリック識別子から導出された値であるバイオメトリックキーＫｂｉｏを提示する。ブリッジデバイス１１０は、好ましくは、Ｋｐｗ１５０及び／又はＫｂｉｏ１５５をしばらくの間記憶することなく、スマートカードリーダ１３０を介してパーソナルパスワードＫｐｗ１５０及びバイオメトリックキーＫｂｉｏ１５５をスマートカード１４０に引き渡す。スマートカード１４０は、Ｋｐｗ１５０及びＫｂｉｏ１５５を使用して、ＫｄｅｖＡ１７０を解読することができる（すなわち、スマートカードは、Ｋｐｗ１５０及びＫｂｉｏ１５５を使用して、ＫｄｅｖＡ１７０を求めることができる）。特定の実施形態では、認証が完了するまで、暗号化されていないＫｄｅｖＡ１７０が、当初、スマートカード１４０のＲＡＭ若しくは他のメモリ又はストレージ素子１４５に存在する場合がある。認証が行われると、好ましくは、ＫｄｅｖＡ１７０は、その後、削除され、ＫｄｅｖＡ１７０の暗号化された形態に置き換えられる。代替的に、スマートカード１４０の代わりに非電子的な認証マテリアルを、ＩＭＤのＫｄｅｖＡがテキスト又はバーコードの形態で印刷された非電子的カードの形態でブリッジデバイス１１０に提供することができる。ＩＭＤのＫｄｅｖＡは、ＢＡＮによって、図３のプロトコルに従い伝播される。 When setting up or initializing a BAN containing an IMD and propagating a BAN key according to the protocol described above, the patient first provides his / her IMD authentication material (eg, smart card 140) to the bridge device 110. This smart card 140 can be issued with the IMD 115 (and given to the patient after surgery), for example, or the necessary information can be entered on the pre-existing patient's smart card device 140. In certain embodiments, the patient inserts his smart card 140 (here, via the interface device 130) into the bridge device 110 and then enters his personal password K pw 150 into the bridge device 110. (Preferably input from the patient's own personal memory, via the GUI that is implemented in the programmer 110 or via an appropriate separate interface), and the fingerprint 155 or A biometric key K bio , which is a value derived from the patient's unique biometric identifier, such as a retinal scan, is presented. The bridge device 110 preferably stores the personal password K pw 150 and biometric key K bio 155 on the smart card 140 via the smart card reader 130 without storing the K pw 150 and / or K bio 155 for a while. hand over. Smart card 140 can decrypt K devA 170 using K pw 150 and K bio 155 (ie, the smart card uses K pw 150 and K bio 155 to determine K devA 170. be able to). In certain embodiments, unencrypted K devA 170 may initially reside in RAM or other memory or storage element 145 of smart card 140 until authentication is complete. Once authenticated, preferably K devA 170 is then deleted and replaced with an encrypted form of K devA 170. Alternatively, non-electronic authentication material can be provided to the bridge device 110 in the form of a non-electronic card in which the IMD's K devA is printed in the form of text or barcode instead of the smart card 140. The IMD K devA is propagated by the BAN according to the protocol of FIG.

本発明のこの実施形態のキー配信プロトコルは、ＩＭＤからブリッジデバイスへの現在のＢＡＮキーのセキュア無線配信、及びブリッジデバイスからＩＭＤへの現在のＢＡＮキーのセキュア無線配信を、もっぱら患者のＢＡＮ内において提供する。このプロトコルは、さらに、ＢＡＮキーそのものだけでなく、送信者及び受信者の認証及び検証も実行する。その上、本発明は、スマートカード１４０が通信に利用可能であることが必要条件であるために、攻撃者が、攻撃者のＢＡＮ内へデバイスを組み入れたり、ＢＡＮキーの配信中にデバイスになりすましたり、配信プロセスそのものを盗聴したり、以前の通信の複製に基づいて反復攻撃を企てたりすることも防止する。好ましくは、ＫｄｅｖＡキーは、ブリッジデバイス１１０上ではなく、スマートカード１４０上にセキュアに留まる。したがって、たとえブリッジデバイス１１０が攻撃者に盗まれた場合であっても、攻撃者は、デバイスキーＫｄｅｖＡを知ることは決してない。本明細書で一般にＫｄｅｖＸ（ＫｄｅｖＡ１７０等）として示されるデバイスキーは、好ましくは、アリス１１５等の埋め込みデバイスに関しては工場でプログラミングされ、ブリッジデバイス１１０、スマートローカルデバイス、及びダムローカル（dumb-local）デバイスに関しても同様に工場でプログラミングすることができる。これらの後者のデバイスは、外部でラベル付けされたＫｄｅｖを有することもできるし、必要に応じて生成されて割り当てられた乱数Ｋｄｅｖを有することもできる。ダムローカルデバイスの限界のために（特に、ダムローカルデバイスがヒューマンインターフェースを有しないという点で）、このようなデバイスは、好ましくは、工場で割り当てられて外部でラベル付けされたＫｄｅｖＸを有する。代替的に、本明細書で説明する、工場で割り当てられる実施態様又は工場でプログラミングされる実施態様のいずれも、通常の「ファームウェアアップグレード」手順を介したフラッシュメモリの更新に付随して供給されるＫｄｅｖＸ又は類似の情報を代わりに有することができる。本明細書では、異なるキー値及び他の変数を指定するのに、次の省略形が使用される。ＫｄｅｖＸは、Ｘの名称を有する指定されたノードの秘密デバイスキーである。ＫＢＡＮは、現在のＢＡＮセッションキーである。ＩＤＸは、デバイスＩＤである。ここで、Ｘは、指定されたノードの名称である。 The key distribution protocol of this embodiment of the present invention provides secure wireless distribution of the current BAN key from the IMD to the bridge device and secure wireless distribution of the current BAN key from the bridge device to the IMD, exclusively within the patient's BAN. provide. This protocol also performs sender and recipient authentication and verification as well as the BAN key itself. Moreover, because the present invention requires that the smart card 140 be available for communication, an attacker can incorporate the device into the attacker's BAN or impersonate the device during delivery of the BAN key. And eavesdropping on the delivery process itself and attempting replay attacks based on duplication of previous communications. Preferably, the K devA key remains securely on the smart card 140, not on the bridge device 110. Therefore, even if the bridge device 110 is stolen by the attacker, the attacker never knows the device key KdevA . Device keys generally referred to herein as K devX (such as K devA 170) are preferably programmed at the factory for embedded devices such as Alice 115, bridge devices 110, smart local devices, and dumb- Local) devices can be programmed at the factory as well. These latter devices can have an externally labeled K dev or can have a random number K dev generated and assigned as needed. Due to the limitations of dumb local devices (particularly in that dumb local devices do not have a human interface), such devices preferably have a K devX assigned at the factory and labeled externally. Alternatively, any of the factory-assigned or factory-programmed embodiments described herein are supplied in conjunction with flash memory updates via a normal “firmware upgrade” procedure. K devX or similar information can be included instead. Herein, the following abbreviations are used to specify different key values and other variables. K devX is the secret device key of the designated node having the name X. K BAN is the current BAN session key. ID X is a device ID. Here, X is the name of the designated node.

本発明の代表的な実施形態におけるさまざまなプライバシー及びメッセージの完全性の機能を実施するのに適したセキュリティ方式は、次世代暗号化標準（「ＡＥＳ」）である。ＡＥＳは、Ｒｉｎｊｄａｅｌと類似しているが、固定のブロックサイズ及びキーサイズを有し、米国連邦政府及び通信業界によって一般に使用される標準である。ＡＥＳは、本明細書でさらに説明するように、構成ＣＴＲ＋ＣＢＣ−ＭＡＣで適切に使用することができる。   A suitable security scheme for implementing various privacy and message integrity functions in exemplary embodiments of the present invention is the Next Generation Encryption Standard ("AES"). AES is similar to Rinjdael but has a fixed block size and key size and is a standard commonly used by the US federal government and the communications industry. AES can be used appropriately with configuration CTR + CBC-MAC, as further described herein.

ＢＡＮキーは、特定のキーの実施形態では、体内デバイス、特にＩＭＤ１１５等の埋め込み物から、ＢＡＮ１００の他の体外「ブリッジ」デバイス１１０へセキュアに通信される。また、ＢＡＮキーは、ＢＡＮ１００のブリッジデバイス１１０から埋め込み物１１５へもセキュアに通信されるべきである。本発明の実施形態によれば、２つの体外デバイス１１０間の通信又は体内デバイス１１５と体外デバイス１１０との間の通信を提供する基礎となる通信セッション１２０が存在する。この通信セッション１２０は、セキュアにされていない場合がある。セキュア通信（このようなセキュリティは、暗号化だけでなく完全性及び新しさの確証も含む）は、埋め込まれたデバイス１１５によって保持された認証マテリアルによって提供される。埋め込みデバイス１１５は、ＢＡＮキーをブリッジデバイス１１０へ配信する。ブリッジデバイス１１０は、適切な認証マテリアル１６０と、乱数生成ファシリティ１６５等のプロセスとを所有する。埋め込まれたデバイス１１５は、適切な認証マテリアル１６０とプロセスとを所有するブリッジデバイス１１０からＢＡＮキーを受信することもできる。本発明の実施形態によれば、以下のプロトコルによって、本発明のセキュリティプロトコルを使用できるブリッジデバイスへのＢＡＮキーのセキュアな無線配信が可能になる。   The BAN key is securely communicated from an in-vivo device, particularly an implant such as the IMD 115, to other extracorporeal “bridge” devices 110 in the BAN 100 in certain key embodiments. The BAN key should also be securely communicated from the bridge device 110 of the BAN 100 to the implant 115. In accordance with an embodiment of the present invention, there is an underlying communication session 120 that provides communication between two extracorporeal devices 110 or communication between intracorporeal device 115 and extracorporeal device 110. This communication session 120 may not be secured. Secure communications (such security includes not only encryption but also integrity and novelty verification) is provided by authentication material held by the embedded device 115. The embedded device 115 distributes the BAN key to the bridge device 110. The bridge device 110 owns the appropriate authentication material 160 and processes such as the random number generation facility 165. The embedded device 115 may also receive a BAN key from the bridge device 110 that owns the appropriate authentication material 160 and process. According to an embodiment of the present invention, the following protocol enables secure wireless distribution of a BAN key to a bridge device that can use the security protocol of the present invention.

図２は、本発明の特定の実施形態によるネットワークノード間のネットワークキーのセキュアな送信のプロトコルを示している。図２に示すように、埋め込みアリス１１５は、ボブ１１０がＢＡＮキーを確立又は取得することを望むことをアリス１１５に示す「ＢＡＮキーを配信する（deliver BAN-key）」セッション要求２１０をブリッジデバイスのボブ１１０から受信する。アリス１１５及びボブ１１０は、最初に、テレメトリック通信セッション２１５を開始しなければならない。このテレメトリック通信セッションでは、アリス１１５は、新しく生成された乱数ＱＡをボブ１１０に提供する。次に、アリス１１５の人間のアドミニストレータ（たとえば、アリスデバイス１１５が埋め込まれた患者）は、スマートカードリーダを通じて電子認証マテリアル（ＥＡＭ）、たとえばスマートカード１４０をボブ１１０に提示しなければならない。この認証マテリアルは、通常、スマートカード１４０又はＵＳＢ／ＩＥＥＥ１３９４（「Ｆｉｒｅｗｉｒｅ（登録商標）」）フォブの形態を取り、図１のアリスのデバイスキー１７０（オプションとして暗号化されている）ＫｄｅｖＡ、１７５、アリスのＩＤ番号ＩＤＡ、及び使用されるブロック暗号（たとえば、１２８ビットＡＥＳ）を実施できるオンボードマイクロプロセッサを含むものである。ＥＡＭ１４０上に存在するＫｄｅｖＡ１７０のコピーも暗号化される場合、アリスの人間のオペレータは、ＰＩＮ又はパスワード入力及びオプションのバイオメトリックデータ１５５等、デバイスキー１７０を解読するのに必要な秘密情報も、たとえばキーパッド入力（図示せず）を介してボブ１１０に手動で与えるべきである。これらのステップが完了すると、ボブ１１０は、メッセージ２２０を準備してＥＡＭ１４０へ配信する。メッセージ２２０は、次のもの、すなわち、電子認証マテリアル１４０上に存在するＫｄｅｖＡ１７０のコピーを解読するのに必要なＱＡ、ＩＤＡ、ＩＤＢ、及び（必要に応じて）秘密情報２２５（ＰＷ１５０及びバイオメトリックデータ１５５）を含む。この即座のトランザクションに続いて、ボブ１１０は、好ましくは、ＰＷ１５０のあらゆるローカルな記録及びあらゆるバイオメトリック情報１５５を削除する。ＥＡＭ１４０は、以下で詳細に説明するように、その組み込まれたマイクロプロセッサ１８０を使用して、２つの１２８ビット乱数Ｑ１及びＱ２を生成する。次に、ＥＡＭ１４０は、キー入力としてＫｄｅｖＡ１７０を使用し、ノンスとしてＱＡを使用して、アリス１１５への、ブロック暗号でセキュアにされたメッセージ２３０を準備する。このセキュアにされたメッセージ２３０は、暗号化されたペイロードとしてＩＤＡ、ＩＤＢ、Ｑ１、及びＱ２を含む。次に、ＥＡＭ１４０は、このセキュアにされたメッセージ２３０を、Ｑ１及びＱ２の「セキュアにされていない」（すなわち、平文）コピーと共にボブ１１０へ渡す。次に、ボブ１１０は、ＥＡＭ１４０からアリス１１５への配達人として機能して、ＥＡＭ１４０のセキュアにされたメッセージ２３０をメッセージ２３５としてアリスへ送信し、Ｑ１及びＱ２のセキュアにされていないコピーを一時的に記憶する。アリス１１５が、ボブのテレメトリー送信２３５を経由してＥＡＭのメッセージ２３０を受信すると、アリス１１５は、メッセージ２３５を即座に解読し、自身のＩＤ１７５が正確であることを検証し、次いで、ボブのＩＤ（図１の１８２）を検証する。アリスが受信したメッセージ２３５が、その完全性チェックに合格した場合、メッセージ２３５がＫｄｅｖＡ１７０及びＱＡを使用してセキュアにされたものであるという理由で、メッセージ２３５は真正なもの（ボブ１１０を介してアリスの患者のＥＡＭ１４０からのもの）及び新鮮なものの双方であるということが、アリス１１５に保証される。 FIG. 2 illustrates a protocol for secure transmission of network keys between network nodes according to a particular embodiment of the present invention. As shown in FIG. 2, embedded Alice 115 sends a “deliver BAN-key” session request 210 indicating to Alice 115 that Bob 110 wants to establish or obtain a BAN key. From Bob 110. Alice 115 and Bob 110 must first initiate a telemetric communication session 215. In this telemetric communication session, Alice 115 provides Bob 110 with a newly generated random number Q A. Next, the human administrator of Alice 115 (eg, the patient in which Alice device 115 is implanted) must present electronic authentication material (EAM), eg, smart card 140, to Bob 110 through a smart card reader. This authentication material typically takes the form of a smart card 140 or USB / IEEE 1394 (“Firewire®”) fob, Alice's device key 170 of FIG. 1 (optionally encrypted) K devA 175 , Alice's ID number ID A , and an on-board microprocessor that can implement the block cipher used (eg, 128-bit AES). If a copy of K devA 170 present on EAM 140 is also encrypted, Alice's human operator will also have the secret information necessary to decrypt device key 170, such as PIN or password entry and optional biometric data 155. Should be manually provided to Bob 110, for example via a keypad input (not shown). When these steps are complete, Bob 110 prepares message 220 and delivers it to EAM 140. The message 220 includes the following: Q A , ID A , ID B , and (optionally) confidential information 225 (which is necessary to decrypt the copy of K devA 170 present on the electronic authentication material 140. PW150 and biometric data 155). Following this immediate transaction, Bob 110 preferably deletes any local record of PW 150 and any biometric information 155. The EAM 140 uses its embedded microprocessor 180 to generate two 128-bit random numbers Q 1 and Q 2 as will be described in detail below. The EAM 140 then prepares a block 230 secured message 230 to Alice 115 using K devA 170 as the key input and Q A as the nonce. This secured message 230 includes ID A , ID B , Q 1 , and Q 2 as encrypted payloads. EAM 140 then passes this secured message 230 to Bob 110 along with the “unsecured” (ie, plaintext) copies of Q 1 and Q 2 . Bob 110 then acts as a deliverer from EAM 140 to Alice 115, sends EAM 140's secured message 230 to Alice as message 235, and sends an unsecured copy of Q 1 and Q 2 Memorize temporarily. When Alice 115 receives EAM message 230 via Bob's telemetry transmission 235, Alice 115 immediately decrypts message 235, verifies that his ID 175 is correct, and then Bob's ID (182 in FIG. 1) is verified. If message 235 received by Alice passes its integrity check, message 235 is authentic (Bob 110) because it was secured using K devA 170 and Q A. Through Alice's patient EAM 140) and fresh one is guaranteed to Alice 115.

アリス１１５が、ＢＡＮキーをボブ１１０へ配信する場合、アリス１１５は、Ｑ１及び Alice 115, when delivering the BAN key to Bob 110, Alice 115, Q 1 and

Figure 2010507928
から成るセキュアにされていないメッセージ２４０を準備して、ボブ１１０へ送信することができる。ここで、ＫＢＡＮは、現在のＢＡＮ１００のキーである。ボブ１１０は、アリスのメッセージ２４０を受信すると、自身のローカルなＱ１が、アリスが送信したＱ１と一致する（それによって、アリス１１５がＥＡＭ１４０の「所有者」であること、すなわち、ＥＡＭ１４０がアリスの秘密デバイスキーＫｄｅｖＡ１７０に対応することがボブ１１０に保証される）ことを検証し、自身のローカルなＱ２を、受信された
Figure 2010507928
 An unsecured message 240 consisting of can be prepared and sent to Bob 110. Here, K BAN is a key of the current BAN 100. Bob 110 receives the message 240 of Alice, the local to Q 1 itself, Alice to (thereby match the Q 1 which is transmitted, Alice 115 is the "owner" of EAM140, i.e., is EAM140 Bob 110 is guaranteed to correspond to Alice's secret device key K devA 170) and received his local Q 2

Figure 2010507928
とＸＯＲし、その結果はＫＢＡＮになる。
Figure 2010507928
 XOR, and the result is K BAN .

他方、アリス１１５が、ボブ１１０からＢＡＮキーを受信する場合、アリス１１５は、Ｑ１から成る、セキュアにされていないメッセージ２４５を準備してボブ１１０へ送信することができる。ボブ１１０は、アリスのメッセージ２４５を受信すると、自身のローカルなＱ１が、アリスが送信したＱ１と一致する（それによって、アリス１１５がＥＡＭ１４０の「所有者」であること、すなわち、ＥＡＭ１４０がアリスの秘密デバイスキーＫｄｅｖＡ１７０に対応することがボブ１１０に保証される）ことを検証する。次に、ボブ１１０は、 On the other hand, Alice 115, when receiving the BAN key from Bob 110, Alice 115 consists Q 1, it may be transmitted to prepare a message 245 that is not secure to Bob 110. Bob 110 receives the message 245 of Alice, the local to Q 1 itself, Alice to (thereby match the Q 1 which is transmitted, Alice 115 is the "owner" of EAM140, i.e., is EAM140 Bob 110 is guaranteed to correspond to Alice's secret device key K devA 170). Next, Bob 110

Figure 2010507928
を含む、セキュアにされていないメッセージ２５０を準備してアリス１１５へ送信することができる。アリス１１５は、ボブのメッセージ２５０を受信すると、自身のローカルなＱ２を、受信されたメッセージ２５０の
Figure 2010507928
 A non-secured message 250 including can be prepared and sent to Alice 115. When Alice 115 receives Bob's message 250, Alice 115 obtains her local Q 2 from the received message 250.

Figure 2010507928
とＸＯＲし、その結果はＫＢＡＮになる。
Figure 2010507928
 XOR, and the result is K BAN .

図３は、図１及び図２のＥＡＭ１４０以外の認証アイテムを使用する、ボディエリアネットワークキー送信プロトコルの代替的な一実施形態を示している。この実施形態によれば、あまり高度でない非電子的認証マテリアルを使用するあまりセキュアでないプロトコルが次のように進行し得る。すなわち、プロトコル３００のこの実施形態によれば、ボブ１１０は、すでに述べたように「ＢＡＮキーを配信する」セッション要求２１０を開始することができ、埋め込み物１１５であるアリスは、「ＢＡＮキーを配信する」セッション要求２１０を、ボブ１１０であるブリッジデバイスから受信する。アリス１１５及びボブ１１０は、最初に、テレメトリック通信セッション２１５を開始しなければならない。このテレメトリック通信セッションでは、アリス１１５は、新しく生成された乱数ＱＡをボブ１１０に提供する。次に、アリス１１５の人間のアドミニストレータ（たとえば、アリスデバイスが埋め込まれた患者）は、３１０において、ＫｄｅｖＡ１７０及びＩＤＡ１７５から成る非電子的な認証マテリアルをボブ１１０に提示することができる。この認証マテリアルは、たとえば、英数字文字で又はバーコードとして認証カード上に印刷して、光学式スキャナリーダデバイスで読み出すことができる。この光学式スキャナリーダデバイスは、たとえば、ボブの内部のもの又はボブに不可欠なものとすることができるか、又は代替的に、ボブと信号通信する（たとえば、ボブとネットワーク接続された）別個のデバイスとすることができる。代替的に、認証マテリアルは、人間のアドミニストレータが、ＧＵＩを介して又はキーパッドに認証マテリアルをタイプ入力することによって、ブリッジデバイスのボブ１１０内へ手動で直接入力することもできる。次に、ボブ１１０は、（本明細書で説明したように、又は他の手段によって）自身のブロック暗号を使用して、上述したような２つの１２８ビット乱数Ｑ１及びＱ２を生成する。次に、ボブ１１０は、キー入力としてＫｄｅｖＡ１７０を使用し、ノンスとしてＱＡを使用して、アリス１１５への、ブロック暗号でセキュアにされたメッセージ２３５を準備する。このセキュアにされたメッセージ２３５は、ＩＤＡ１７５、ＩＤＢ１８２、Ｑ１、及びＱ２を含む。次に、ボブ１１０は、このセキュアにされたメッセージ２３５をアリス１１５へ送信し、Ｑ１及びＱ２のセキュアにされていないコピーを一時的に記憶する。アリス１１５が、ボブのメッセージ２３５を受信すると、アリス１１５は、そのメッセージを即座に解読し、自身のＩＤ１７５が正確であることを検証し、次いで、ボブのＩＤ１８２を検証する。アリスが受信したメッセージ２３５が、その完全性チェックに合格した場合、メッセージ２３５がＫｄｅｖＡ１７５及びＱＡを使用してセキュアにされたものであるという理由で、メッセージ２３５は真正なもの（すなわち、ボブ１１０からのもの）及び新鮮なものの双方であるということが、アリス１１５に保証される。他のＢＡＮキーの生成及び送信は、上述したように行われる。 FIG. 3 illustrates an alternative embodiment of a body area network key transmission protocol that uses an authentication item other than EAM 140 of FIGS. According to this embodiment, a less secure protocol using less sophisticated non-electronic authentication material may proceed as follows. That is, according to this embodiment of the protocol 300, Bob 110 can initiate a “Distribute BAN key” session request 210 as previously described, and Alice, the embedded 115, can “ A “deliver” session request 210 is received from a bridge device that is Bob 110. Alice 115 and Bob 110 must first initiate a telemetric communication session 215. In this telemetric communication session, Alice 115 provides Bob 110 with a newly generated random number Q A. Next, a human administrator of Alice 115 (eg, a patient with an implanted Alice device) can present a non-electronic authentication material consisting of K devA 170 and ID A 175 to Bob 110 at 310. The authentication material can be printed on the authentication card, for example, as alphanumeric characters or as a barcode, and read with an optical scanner reader device. This optical scanner reader device can be, for example, internal to Bob or integral to Bob, or alternatively a separate signal in communication with Bob (eg, networked with Bob) It can be a device. Alternatively, the authentication material may be manually entered directly into Bob 110 of the bridge device by a human administrator via the GUI or by typing the authentication material into the keypad. Bob 110 then uses his block cipher (as described herein or by other means) to generate two 128-bit random numbers Q 1 and Q 2 as described above. Bob 110 then prepares a block cipher secured message 235 to Alice 115 using K devA 170 as the key input and Q A as the nonce. This secured message 235 includes ID A 175, ID B 182, Q 1 , and Q 2 . Bob 110 then sends this secured message 235 to Alice 115 and temporarily stores an unsecured copy of Q 1 and Q 2 . When Alice 115 receives Bob's message 235, Alice 115 immediately decrypts the message, verifies that her ID 175 is correct, and then verifies Bob's ID 182. Message 235 Alice received, if it passes its integrity check, the reason that the message 235 is one that is secure by using the K Deva 175 and Q A, the message 235 as genuine (i.e., Alice 115 is guaranteed to be both fresh and fresh from Bob 110. Other BAN keys are generated and transmitted as described above.

アリス１１５が、ＢＡＮキーをボブ１１０へ配信する場合、アリス１１５は、Ｑ１及び Alice 115, when delivering the BAN key to Bob 110, Alice 115, Q 1 and

Figure 2010507928
から成るセキュアにされていないメッセージ２４０を準備して、ボブ１１０へ送信することができる。ここで、ＫＢＡＮは、現在のＢＡＮ１００のキーである。ボブ１１０は、アリスのメッセージ２４０を受信すると、自身のローカルなＱ１が、アリスが送信したＱ１と一致する（それによって、アリス１１５がＥＡＭ１４０の「所有者」であること、すなわち、ＥＡＭ１４０がアリスの秘密デバイスキーＫｄｅｖＡ１７０に対応することがボブ１１０に保証される）ことを検証し、自身のローカルなＱ２を、受信された
Figure 2010507928
 An unsecured message 240 consisting of can be prepared and sent to Bob 110. Here, K BAN is a key of the current BAN 100. Bob 110 receives the message 240 of Alice, the local to Q 1 itself, Alice to (thereby match the Q 1 which is transmitted, Alice 115 is the "owner" of EAM140, i.e., is EAM140 Bob 110 is guaranteed to correspond to Alice's secret device key K devA 170) and received his local Q 2

Figure 2010507928
とＸＯＲし、その結果はＫＢＡＮになる。他方、アリス１１５が、ボブ１１０からＢＡＮキーを受信することを望む場合、アリス１１５は、Ｑ１から成る、セキュアにされていないメッセージを準備してボブ１１０へ送信することができる。ボブ１１０は、アリスのメッセージを受信すると、自身のローカルなＱ１が、アリスが送信したＱ１と一致する（それによって、アリス１１５がＥＡＭ１４０の「所有者」であること、すなわち、ＥＡＭ１４０がアリスの秘密デバイスキーＫｄｅｖＡ１７０に対応することがボブ１１０に保証される）ことを検証する。次に、ボブ１１０は、
Figure 2010507928
 XOR, and the result is K BAN . On the other hand, Alice 115, wish to receive the BAN key from Bob 110, Alice 115 consists Q 1, may be transmitted to Bob 110 prepares a message that is not secure. Bob 110 receives Alice's message and local to Q 1 itself, Alice by consistent (it with Q 1 which is transmitted, Alice 115 is the "owner" of EAM140, i.e., Alice EAM140 Bob 110 is guaranteed to correspond to the secret device key K devA 170 of Next, Bob 110

Figure 2010507928
を含む、セキュアにされていないメッセージを準備してアリスへ送信する。アリスは、ボブのメッセージを受信すると、自身のローカルなＱ２を、受信された
Figure 2010507928
 Prepare and send an unsecured message containing A to Alice. When Alice received Bob's message, she received her local Q 2

Figure 2010507928
とＸＯＲし、その結果はＫＢＡＮになる。
Figure 2010507928
 XOR, and the result is K BAN .

本発明の実施形態は、送受信機モジュールが属するデバイスのクラスに依存して、製造者が、そのモジュールを少なくとも４つの永久的な状態のうちの１つにすることができるシステムを提供する。これらのクラスは、一般に、（１）埋め込みデバイス（ＩＭＤ）、（２）ブリッジデバイス、（３）スマートローカルデバイス、及び（４）ダムローカルデバイスとしてカテゴリー化することができる。スマートローカルデバイスは、ユーザ入力用のファシリティ（たとえば、外部の薬ポンプ、外部の血糖計コントローラ、及び埋め込みコントローラ）を含む広範囲のグラフィカルユーザインターフェース（ＧＵＩ）を有するデバイスである。ブリッジデバイスは、広範囲のＧＵＩ及びユーザ入力を有し、さらに、埋め込みデバイス（たとえば、医師プログラマ、並びに、より機能豊富で強力な埋め込みコントローラ及びホームモニタ）に対して自身を認証することができる。ダムローカルデバイスは、ＧＵＩもユーザ入力も有しないデバイスである。ただし、或る限られたユーザディスプレイが存在する場合がある。ダムローカルデバイスには、キーフォブ、外部の血糖計、コムリンク、並びに特定の限られた能力の患者コントローラ及びホームモニタが含まれ得る。   Embodiments of the present invention provide a system that allows a manufacturer to put the module in one of at least four permanent states, depending on the class of device to which the transceiver module belongs. These classes can generally be categorized as (1) embedded devices (IMD), (2) bridge devices, (3) smart local devices, and (4) dumb local devices. A smart local device is a device having a wide range of graphical user interfaces (GUIs) including facilities for user input (eg, an external drug pump, an external blood glucose meter controller, and an embedded controller). The bridge device has a wide range of GUI and user inputs, and can further authenticate itself to embedded devices (eg, physician programmers and more feature-rich and powerful embedded controllers and home monitors). A dumb local device is a device that has no GUI or user input. However, there may be some limited user display. Dumb local devices may include key fobs, external blood glucose meters, comlinks, and certain limited capacity patient controllers and home monitors.

ＢＡＮのさまざまなノードを構成するデバイスのタイプにかかわらず、これらのデバイスが、必要な最小の計算資源とセキュアに通信するために、すべてのデバイスは、好ましくは、ＢＡＮキーＫＢＡＮを共有する。たとえば、本発明によれば、ブリッジデバイス及び／又はスマートローカルデバイスは、セッション単位で、他のブリッジデバイス、スマートローカルデバイス、ダムローカルデバイス、及び埋め込まれたデバイスへ正当なＢＡＮキーを配信することができ、具体的には、埋め込みデバイスは、ＢＡＮの認可されたブリッジデバイス（たとえば、プログラマ機器）へ現在のＢＡＮキーをセキュアに配信するか、又は、認可されたブリッジデバイス（たとえば、プログラマ機器）から現在のＢＡＮキーをセキュアに受信する。本発明の特定の実施形態では、ＢＡＮキーの配信中のデバイスなりすまし、ＢＡＮキー配信の盗聴、及び／又は反射攻撃（すなわち、実質的なメッセージの内容の部分的な理解若しくは推測のみを含むか、又は、そのような理解も含まない、盗聴された通信の単なる繰り返し）を防止するか又は妨げるキー配信プロトコルが使用される。体外（すなわち、身体の外部）のＢＡＮデバイスは、ＩＭＤの秘密デバイスキーを決して受信しないので、プログラマ等の患者のＢＡＮのデバイスは、ＩＭＤの一意のデバイスキーを知ることは決してなく、一意のデバイスキーは、常に秘密の状態に維持されて、通信されず、たとえ、そのＩＭＤのＢＡＮで使用される体外機器が喪失又は盗難されても、存在するセッション認証情報は使用されていないものとなり、ＩＭＤの秘密キーは、体外機器上に決して記憶されていないので、ＩＭＤは危険にさらされない。ＢＡＮキーは、好ましくは、ＢＡＮの体外デバイス（たとえば、ブリッジデバイス及びスマートローカルデバイス）からＢＡＮの他の体外デバイス（たとえば、ブリッジデバイス、スマートローカルデバイス、及びダムローカルデバイス）へセキュアに通信される。これを行うために、本発明の特定の実施形態では、基礎となる無線通信方法の標準的なハンドシェイク、セッション要求、又は他のあらかじめ確立されたプロトコルに従って、セキュアにされていないテレメトリーセッションが確立される。ＢＡＮキーを受信するデバイスは、人間によって管理されている場合、ＢＡＮキーを配信するデバイスを操作する人間がＢＡＮキー受信者の認証を検証できるようにするために、その人間に、受信デバイスのデバイスキーＫｄｅｖ及び受信デバイスのＩＤ番号を視覚的に提供できなければならない。特にデバイスキーＫｄｅｖは、好ましくは、最初のデバイスが通過するすべてのデバイスから一意であるわけではない場合でも、少なくともＢＡＮに組み込まれる他のデバイスに対して一意である。また、特定の実施形態では、スマートローカルデバイス及びブリッジデバイスは、自身に提供されているかも知れないＢＡＮキーを、ＢＡＮの他の適任のデバイス（すべてのダムローカルデバイス及び／又は他のスマートローカルデバイス及び／又は他のブリッジデバイス）へセキュアに配信するのに使用される。本発明の代表的な実施形態によれば、ＢＡＮキーは、ＢＡＮの無線接続機能を介してセキュアに提供される。 Regardless of the type of devices that make up the various nodes of the BAN, in order for these devices to communicate securely with the minimum computational resources required, all devices preferably share a BAN key K BAN . For example, according to the present invention, a bridge device and / or smart local device may deliver a legitimate BAN key to other bridge devices, smart local devices, dumb local devices, and embedded devices on a per session basis. Specifically, the embedded device can securely distribute the current BAN key to a BAN authorized bridge device (eg, programmer equipment) or from an authorized bridge device (eg, programmer equipment). Receive the current BAN key securely. Certain embodiments of the present invention may include device spoofing during BAN key distribution, eavesdropping of BAN key distribution, and / or replay attacks (i.e., including only partial understanding or guessing of the substantial message content, Alternatively, a key distribution protocol is used that prevents or prevents eavesdropping (simply repeated eavesdropping communications) that does not involve such understanding. Since the BAN device outside the body (ie outside the body) never receives the IMD's secret device key, the patient's BAN device, such as a programmer, never knows the IMD's unique device key; The key is always kept secret and not communicated, even if the extracorporeal device used in that IMD's BAN is lost or stolen, the existing session authentication information will be unused, and the IMD Is never stored on the extracorporeal device, so the IMD is not compromised. The BAN key is preferably securely communicated from the BAN extracorporeal devices (eg, bridge devices and smart local devices) to the BAN's other extracorporeal devices (eg, bridge devices, smart local devices, and dumb local devices). To do this, certain embodiments of the present invention establish an unsecured telemetry session according to the standard handshake, session request, or other pre-established protocol of the underlying wireless communication method. Is done. If the device that receives the BAN key is managed by a human, the human operating the device that distributes the BAN key may ask the human to receive the device of the receiving device in order to be able to verify the authentication of the BAN key recipient. It must be possible to visually provide the key K dev and the ID number of the receiving device. In particular, the device key K dev is preferably unique to at least other devices incorporated in the BAN, even if it is not unique from all devices that the first device passes through. Also, in certain embodiments, the smart local device and the bridge device may send a BAN key that may be provided to the other suitable device of the BAN (all dumb local devices and / or other smart local devices). And / or other bridge devices). According to an exemplary embodiment of the present invention, the BAN key is securely provided via the BAN's wireless connection function.

図４は、本発明の一実施形態による２つの体外デバイスを有するボディエリアネットワーク４００を示している。この実施形態では、前の例のようなＩＭＤではなく、スマートローカルデバイス４１５又はブリッジデバイス４２０等の体外デバイスへＢＡＮキーを配信する体外デバイス（アリス）４１０が、ＢＡＮキー配信要求を開始することができる。前のＢＡＮキー伝播の例と同様に、テレメトリック通信セッションが、非セキュアチャネル１２０を介して（たとえば、ハンドシェイク又は他のあらかじめ確立された互換性のあるセッションプロトコルによって）、ＢＡＮキーを受信するデバイス（ボブ）１１０と確立され、ボブ１１０は、（ボブデバイス１１０のメモリ、ストレージ、又は他のハードウェア若しくはソフトウェアの素子４３５に実装されたＲＮＧファシリティによって生成される）新しく生成された乱数ＱＢを、メッセージ４２５を介してアリス４１０へ送信する必要がある。アリス４１０及びボブ１１０が、本発明に従って、非セキュアチャネル１２０を介して別の方法でテレメトリーセッションを確立すると、アリス４１０（又は、ＢＡＮキー交換セッションを管理する人間）は、ボブのデバイスキーＫｄｅｖＢ４３０を視覚的に獲得することできる（且つ、ＧＵＩ又は他の入力を介してアリス４１０に入力することができる）。デバイスキーＫｄｅｖＢ４３０は、たとえば、ボブの外装に貼付されたラベルに印刷することもできるし、ボブの電子ＧＵＩ上に表示することもでき、また、図４に抽象的に示すオンボードメモリ又はローカルストレージ素子４３５にも記憶される。アリス及びボブは、通常、テレメトリーセッションの最初の時点でＩＤ（ＩＤＡ及びＩＤＢ）を交換し、通信４４５及び４５０を介してそれらの各ＩＤを他の関係者に提供する。ほとんどの場合に、アリス４１０は、ボブ１１０のポーリング又はインターロゲートを行い、メッセージ４４５を介してボブの識別番号（ＩＤＢ）４４０を取得することもできる。 FIG. 4 illustrates a body area network 400 having two extracorporeal devices according to one embodiment of the present invention. In this embodiment, an external device (Alice) 410 that distributes a BAN key to an external device such as smart local device 415 or bridge device 420, rather than an IMD as in the previous example, may initiate a BAN key distribution request. it can. Similar to the previous BAN key propagation example, a telemetric communication session receives a BAN key via the non-secure channel 120 (eg, by handshake or other pre-established compatible session protocol). Established with device (Bob) 110, Bob 110 generates a newly generated random number Q B ( generated by an RNG facility implemented in memory, storage, or other hardware or software element 435 of Bob device 110). Need to be sent to Alice 410 via message 425. When Alice 410 and Bob 110 establish a telemetry session in another way over the non-secure channel 120 in accordance with the present invention, Alice 410 (or the person managing the BAN key exchange session) will have Bob's device key K devB 430 can be obtained visually (and can be entered into Alice 410 via a GUI or other input). The device key K devB 430 can be printed, for example, on a label affixed to Bob's exterior, or displayed on Bob's electronic GUI, Also stored in the local storage element 435. Alice and Bob typically exchange IDs (ID A and ID B ) at the beginning of the telemetry session and provide their respective IDs to other parties via communications 445 and 450. In most cases, Alice 410 can also poll or interrogate Bob 110 and obtain Bob's identification number (ID B ) 440 via message 445.

アリスは、ＩＤＢ４４０及びＫｄｅｖＢ４３０を獲得すると、オンボードメモリ又はセキュアストレージ４５５に記憶されているＩＤＡ（アリスのＩＤ番号）及びＢＡＮキーにアクセスすることができ、ＩＤＡ、ＩＤＢ及び現在のＢＡＮキーＫＢＡＮを含むメッセージ４６０を準備して、ボブへ送信することができる。ＩＤＡ、ＩＤＢ及び現在のＢＡＮキーＫＢＡＮはすべて、（以下で説明するように、ブロック暗号へのノンス入力としてのＱＢと共に）ブロック暗号へのキー入力としてボブのデバイスキーＫｄｅｖＢ４３０を使用してセキュアにされる。ボブ１１０は、アリスの送信４６０を受信すると、ＫｄｅｖＢ４３０を使用してアリスのメッセージ４６０を解読して検証し、受信されたＩＤＡ、ＩＤＢ、及びＫＢＡＮをログ記録する。次に、ボブは、ＩＤＡ、ＩＤＢを含むメッセージ４６５を準備して、アリス４１０へ送信する。ＩＤＡ、ＩＤＢはすべて、ＫＢＡＮ及びＱＢ＋１（すなわち、ＱＢをインクリメントしたもの）でセキュアにされる。アリス４１０は、ボブのメッセージ４６５を受信して解読／検証すると、自身が受信したＩＤが、自身が送信したＩＤと一致することを検証する。 When Alice obtains ID B 440 and K devB 430, she can access ID A (Alice's ID number) and BAN key stored in on-board memory or secure storage 455, where ID A , ID B, and A message 460 containing the current BAN key K BAN can be prepared and sent to Bob. ID A , ID B and the current BAN key K BAN all have Bob's device key K devB 430 as key input to the block cipher (with Q B as nonce input to the block cipher as described below). Use to be secure. Upon receiving Alice's transmission 460, Bob 110 uses K devB 430 to decrypt and verify Alice's message 460 and logs the received ID A , ID B , and K BAN . Next, Bob prepares a message 465 including ID A and ID B and sends it to Alice 410. ID A and ID B are all secured with K BAN and Q B +1 (ie, an increment of Q B ). When Alice 410 receives and decrypts / verifies Bob's message 465, Alice 410 verifies that the ID she received matches the ID she sent.

ダムローカルデバイス４７０の場合、デバイスキーＫｄｅｖＸは、好ましくは、「工場において」ランダム又は任意に選ぶことができ、デバイス４７０内のファームウェア（又は、代替的にフラッシュメモリ）４３５に永久的にプログラミングすることができる。ダムローカルデバイス４７０は、本明細書で定義されるように、一般に、有効なＧＵＩを有しないので、Ｋｄｅｖ４３０は、好ましくは、デバイス４７０の外装、デバイス４７０の文書、又はデバイスそのものに貼付されるべきラベルに印刷され、開始後に除去される。これとは対照的に、スマートローカルデバイス４１５及びブリッジデバイス４２０は、本明細書で定義されるように、ＧＵＩを有し、それによって、自身のデバイスキー４３０を（ダムローカルデバイスと同様に）外部ラベルを経由して利用可能にすることもできるし、デバイスのＧＵＩを通じて利用可能にすることもできる。Ｋｄｅｖは、攻撃者が、認可されていないＢＡＮからテレメトリーノードデバイスにアクセスするために知る必要がある唯一の情報であるので、Ｋｄｅｖをできるだけ秘密の状態に維持することが重要である。スマートローカルデバイス４１５及びブリッジデバイス４２０の場合、デバイスキーＫｄｅｖがオンボードメモリ／ストレージ４３５又は４５５にのみ記憶され、もっぱらデバイスのＧＵＩを経由して利用可能であり、デバイスのＧＵＩとの対話が必要とされる場合に、デバイスの外側に印刷されることとは対照的に、Ｋｄｅｖは、明らかに、よりセキュアである。 In the case of a dumb local device 470, the device key K devX can preferably be chosen “in the factory” randomly or arbitrarily and permanently programmed into the firmware (or alternatively flash memory) 435 in the device 470. be able to. Since the dam local device 470 generally does not have a valid GUI as defined herein, the K dev 430 is preferably affixed to the exterior of the device 470, the device 470 document, or the device itself. It is printed on the label to be removed and removed after the start. In contrast, smart local device 415 and bridge device 420 have a GUI, as defined herein, thereby allowing their device key 430 to be external (similar to a dumb local device). It can be made available via a label or can be made available through the device's GUI. Since K dev is the only information an attacker needs to know to access the telemetry node device from an unauthorized BAN, it is important to keep K dev as secret as possible. For smart local devices 415 and bridge devices 420, the device key K dev is stored only in the onboard memory / storage 435 or 455 and is available exclusively via the device's GUI and requires interaction with the device's GUI. In contrast to being printed outside the device, K dev is clearly more secure.

ＫｄｅｖＢ４３０等のデバイスキーは、好ましくは、（フラッシュメモリ４３５内を含む）ダムローカルデバイス４７０内にハードプログラミングされる一方、スマートローカルデバイス４１５及びブリッジデバイス４２０については、デバイスキーはハードプログラミングされる必要はない。したがって、本発明の特定の実施形態では、スマートローカルデバイス４１５及びブリッジデバイス４２０のデバイスキーのプライバシーは、デバイスキーが必要とされるごとに、デバイスキーがランダムに生成される場合に最大にすることができる。デバイスキーの新しく生成された乱数を使用し、それによって、ＧＵＩを経由してデバイスキーを観察可能にすることを必要とすることによって、新しいデバイスキーが生成されるごとに、可能なデバイスキーの確率分布が（疑似乱数ジェネレータの一様性まで）効果的に一様になるという点で、スマートローカルデバイス４１５及びブリッジデバイス４２０に、ハイジャック（すなわち、認可されてない使用又はアクセス）からの特別な免疫が提供される。これは、デバイスキー４３０を推測しようとしている攻撃者４７５が、新しいデバイスキー４３０が生成されるごとに、自身の検索を最初からやり直す必要があることを意味する。したがって、本発明の特定の実施形態では、新しく生成された乱数が、スマートローカルデバイス４１５及びブリッジデバイス４２０のデバイスキーを生成するのに使用される。すべてのメッセージ、すなわち、ＢＡＮキーによるキー付き（keyed）メッセージ及びデバイスキーによるキー付きメッセージをセキュアにするのにブロック暗号を使用することができる。たとえば、過度のオーバーヘッドなしで強力なセキュリティを与えるブロック暗号は、１２８ビットＡＥＳとすることができる。デバイスキーが、ブロック暗号の長さよりも短い場合、ブロック暗号の引数の長さに達するために必要とされる回数だけ、デバイスキーを繰り返して、それ自体に連結することができる。 Device keys such as K devB 430 are preferably hard programmed into dumb local devices 470 (including in flash memory 435), while for smart local devices 415 and bridge devices 420, device keys are hard programmed. There is no need. Thus, in certain embodiments of the present invention, the device key privacy of smart local device 415 and bridge device 420 is maximized when the device key is randomly generated each time the device key is required. Can do. Each time a new device key is generated, using a newly generated random number of the device key, thereby requiring the device key to be observable via the GUI, The smart local device 415 and bridge device 420 are specially hijacked (ie, unauthorized use or access) in that the probability distribution is effectively uniform (up to pseudo-random number generator uniformity). Immunity is provided. This means that the attacker 475 trying to guess the device key 430 needs to restart his search from the beginning each time a new device key 430 is generated. Thus, in certain embodiments of the present invention, the newly generated random number is used to generate device keys for smart local device 415 and bridge device 420. Block ciphers can be used to secure all messages, ie, keyed messages with BAN keys and keyed messages with device keys. For example, a block cipher that provides strong security without undue overhead can be 128-bit AES. If the device key is shorter than the length of the block cipher, the device key can be repeated and concatenated to itself as many times as necessary to reach the length of the block cipher argument.

図５は、図４のネットワークキー伝播プロトコルを疑似プロトコル表記で示している。このプロトコルは、ＢＡＮキーが、ＢＡＮ４００の体外デバイス（ブリッジデバイス４２０及びスマートローカルデバイス４１５）からＢＡＮ４００の他の体外デバイス（ブリッジデバイス４２０、スマートローカルデバイス４１５、及びダムローカルデバイス４７０のいずれか）へどのようにセキュアに通信されるのかを記述している。ＢＡＮキーを受信するデバイス、この場合、ボブ１１０は、ブリッジデバイス、スマートローカルデバイス、ダムローカルデバイス等の体外デバイスへＢＡＮキーを配信するデバイス（この場合、アリス４１０）を操作する人間に、受信デバイス１１０のデバイスキーＫｄｅｖ４３０及び受信デバイスのＩＤ番号４４０を視覚的に提供できなければならない。最初に、ボブ１１０は、「ＢＡＮキーを配信する」セッション要求２１０をアリス４１０から受信する。アリス４１０及びボブ１１０は、最初に、図４のメッセージ４２５と同様に、ボブ１１０が新しく生成された乱数ＱＢをアリス４１０に提供するテレメトリック通信セッション２１５を開始しなければならない。本発明の特定の実施形態によれば、スマートローカルデバイス４１５及びブリッジデバイス４２０は、ＢＡＮキーを有する場合に、ＢＡＮ４００の他の適任のデバイス（すべてのダムローカルデバイス４７０及び／又は他のスマートローカルデバイス４１５及び／又は他のブリッジデバイス４２０）へＢＡＮキーをセキュアに配信することを担当する。したがって、以下のプロトコルは、適任のＢＡＮ４００のデバイスへのＢＡＮキーのセキュアな無線配信を可能にするのに適切である。 FIG. 5 shows the network key propagation protocol of FIG. 4 in pseudo protocol notation. This protocol allows the BAN key to be transferred from an extracorporeal device of BAN 400 (bridge device 420 and smart local device 415) to another extracorporeal device of BAN 400 (any of bridge device 420, smart local device 415, and dumb local device 470). It describes how to communicate securely. The device receiving the BAN key, in this case, Bob 110, receives the receiving device to the person operating the device (in this case Alice 410) that distributes the BAN key to an extracorporeal device such as a bridge device, smart local device, dumb local device, etc. It should be possible to visually provide 110 device key K dev 430 and receiving device ID number 440. Initially, Bob 110 receives a “Distribute BAN key” session request 210 from Alice 410. Alice 410 and Bob 110 must first initiate a telemetric communication session 215 in which Bob 110 provides Alice 410 with a newly generated random number Q B , similar to message 425 in FIG. According to certain embodiments of the present invention, smart local device 415 and bridge device 420 may have other suitable devices (all dumb local devices 470 and / or other smart local devices) when having a BAN key. 415 and / or other bridge devices 420) is responsible for securely distributing the BAN key. Thus, the following protocol is appropriate to enable secure wireless delivery of BAN keys to qualified BAN 400 devices.

図５に示すように、ＢＡＮキーを配信するデバイス（アリス４１０）によって開始される「ＢＡＮキーを配信する」セッション要求２１０は、まず、ＢＡＮキーを受信するデバイス（ボブ１１０）とのセキュアにされていない通信セッション２１５を確立することから成る。アリス４１０及びボブ１１０がテレメトリーセッションを確立すると、ボブ１１０も、アリス４１０に、新たに生成された６４ビット疑似乱数ＱＢをメッセージ２１５を介して送信する必要がある。 As shown in FIG. 5, the “Distribute BAN Key” session request 210 initiated by the device that distributes the BAN key (Alice 410) is first secured with the device that receives the BAN key (Bob 110). Non-communication session 215 is established. When Alice 410 and Bob 110 establish a telemetry session, Bob 110 also needs to send Alice 410 a newly generated 64-bit pseudorandom number Q B via message 215.

スマートローカルデバイス４１５及びブリッジデバイス４２０のファームウェアが、着信する「ＢＡＮキー配信」コマンド２１０を拒否する場合には、人間のユーザが、スマートローカルデバイス４１５又はブリッジデバイス４２０を「新しいＢＡＮキーを受理する」モードにしない限り、デバイスハイジャックを防止するさらなる極めて強力な方法を実現することができる。新しいＢＡＮキーの受理に人間の介入を必要とすることは、専用の物理ボタン又はスイッチをダムローカルデバイス４７０に追加することによってダムローカルデバイス４７０において実施することができる。   If the firmware of the smart local device 415 and the bridge device 420 rejects the incoming “BAN key distribution” command 210, the human user will “accept the new BAN key” for the smart local device 415 or the bridge device 420. As long as it is not in mode, a much more powerful way of preventing device hijacking can be realized. Requiring human intervention to accept a new BAN key can be implemented at the dumb local device 470 by adding a dedicated physical button or switch to the dumb local device 470.

スマートローカルデバイス４１５及びブリッジデバイス４２０のファームウェア４３５、４５５が、着信する「ＢＡＮキー配信」コマンドを拒否する場合には、デバイスに接近した人間のユーザが、スマートローカルデバイス又はブリッジデバイスを「新しいＢＡＮキーを受理する」モードにしない限り、デバイスハイジャックを防止するさらなる極めて強力な方法を実現することができる。新しいＢＡＮキーの受理に人間の介入を必要とするこのアイデアは、物理ボタン又はスイッチ（埋め込まれた「リセット」ボタン等）をダムローカルデバイス４７０に追加することによってダムローカルデバイス４７０においても実現することができる。新しいＢＡＮキーを受理するのに人間との対話を必要とすることは、実際に、（攻撃者がデバイスとの物理的な接触を達成しないという条件で）起こり得るあらゆるデバイスハイジャックを排除するが、本明細書で説明するように、ＢＡＮキー配信プロトコルに対する他の攻撃は可能であり、本発明の他の実施形態によって対処される。   If the firmware 435, 455 of the smart local device 415 and the bridge device 420 rejects the incoming “BAN key distribution” command, a human user approaching the device may identify the smart local device or bridge device as “new BAN key”. Unless it is in the “accept” mode, a much more powerful way to prevent device hijacking can be realized. This idea of requiring human intervention to accept a new BAN key can also be realized in the dumb local device 470 by adding a physical button or switch (such as an embedded “reset” button) to the dumb local device 470 Can do. Requiring human interaction to accept the new BAN key actually eliminates any possible device hijacking (provided that the attacker does not achieve physical contact with the device) As described herein, other attacks on the BAN key distribution protocol are possible and are addressed by other embodiments of the present invention.

図４及び図５のＢＡＮキー配信プロトコルの最後のステップにおいて、ボブ１１０は、ＫＢＡＮでセキュアにされたメッセージ４６５をアリス４１０へ送信することができ、したがって、キー配信プロトコルが成功したことを確認する。この確認信号は、アプリケーションレイヤに渡すことができ、次いで、視覚信号及び／又は音響信号の形態で「配信成功」通知として人間のユーザへ通信することができる。 In the last step of the BAN key distribution protocol of FIGS. 4 and 5, Bob 110 can send a K BAN secured message 465 to Alice 410, thus confirming that the key distribution protocol was successful. To do. This confirmation signal can be passed to the application layer and then communicated to the human user as a “delivery successful” notification in the form of a visual and / or audio signal.

本発明のブリッジデバイス４２０及びスマートローカルデバイス４１５は、特定の実施形態では、ＢＡＮキーをリセットすることができ、それによって、以下で説明するように、セッションキーもリセットすることができる。たとえば、患者又は医師の命令で、ブリッジデバイス４２０及びスマートローカルデバイス４１５は、受信機のデバイスＩＤ及びデバイスキーを使用することによって、ＢＡＮキーをローカルデバイス４１５、４７０及び／又は他のブリッジデバイス４２０へ配信することができる。本発明の特定の実施形態では、埋め込まれたデバイス又はブリッジデバイス４２０がＢＡＮに存在するか否かにかかわらず、スマートローカルデバイス４１５は、ＢＡＮキーを生成することができる。一般に、ＢＡＮキーを更新する必要がある唯一の時は、ＢＡＮキーを有するデバイスが喪失又は盗難された時である。本発明による特定の実施形態では、現在の攻撃者の処理能力に基づくと、ＢＡＮキーは、危険にさらされることを回避するために約数百年に１度の頻度でしか更新する必要がない。   The bridge device 420 and smart local device 415 of the present invention can reset the BAN key in certain embodiments, thereby resetting the session key as described below. For example, at the patient's or physician's command, the bridge device 420 and smart local device 415 use the device ID and device key of the receiver to transfer the BAN key to the local device 415, 470 and / or other bridge device 420. Can be delivered. In certain embodiments of the invention, smart local device 415 can generate a BAN key regardless of whether an embedded device or bridge device 420 is present in the BAN. In general, the only time a BAN key needs to be updated is when a device with a BAN key is lost or stolen. In certain embodiments according to the present invention, based on the current attacker's processing power, the BAN key only needs to be updated about once every few hundred years to avoid being compromised. .

ネットワーキング資源の制約条件のために、本発明の特定の実施形態では、共通の秘密キーが、特定のボディエリアネットワーク（ＢＡＮ）のすべてのデバイスによって共有される。このＢＡＮキーＫＢＡＮは、ＢＡＮ内のすべての通信をセキュアにするのに使用される。ＢＡＮ内では、テレメトリーセッションを次のように確立することができる。すなわち、テレメトリーセッションを開始するいずれかのデバイスのコマンド時に、共有されたＢＡＮキーが、現在のテレメトリーセッションで通信することを望むすべてのＢＡＮメンバーによって与えられる、新しく生成されて共有される乱数と共に、セッションキーＫｓｅｓにされる。このセッションキーＫｓｅｓは、テレメトリーセッションの継続時間の間、ＢＡＮで通信されるすべてのメッセージをセキュアにするのに使用される。テレメトリーセッションがクローズされると、現在のセッションキーは廃棄される。 Due to networking resource constraints, in certain embodiments of the invention, a common secret key is shared by all devices in a particular body area network (BAN). This BAN key K BAN is used to secure all communications within the BAN. Within the BAN, a telemetry session can be established as follows. That is, at the command of any device that initiates a telemetry session, the shared BAN key is given by all BAN members who wish to communicate in the current telemetry session, along with a newly generated and shared random number, The session key K ses is set. This session key K ses is used to secure all messages communicated over the BAN for the duration of the telemetry session. When the telemetry session is closed, the current session key is discarded.

ノード間の通信セッションをオープンするために、最初に、たとえば、ハンドシェイク、セッション要求／受理、又は他のセッション開始プロトコルによって、セキュアにされていない交換が通信デバイス間で行われる。好ましくは、着信するパケット長及び発信するパケット長は固定であり、その上、本発明による特定の実施形態では、物理レイヤハードウェアが、これらのパケット長を予測するようにセットアップされる。したがって、それよりも短いパケット又は長いパケットを「不良」とフラグ付けして拒絶することができる。使用される、関連のある暗号のインスタンスが利用可能でなければならない。本発明と共に使用するためのさまざまな適切な暗号化標準の１つは、ＦＩＰＳ承認の１２８ビットＡＥＳブロック暗号（ＦＩＰＳ ＰＵＢ １９７）である。暗号化は、ＡＥＳの「カウンタモード」（ＣＴＲモード）で適切に行うことができる。メッセージの新しさは、トークンのようなノンス（すなわち、使い捨ての疑似乱数）の使用を通じてチェックすることができる。また、特定の実施形態では、たとえば、ＡＥＳの「暗号ブロック連鎖メッセージ認証コードモード」（ＣＢＣ−ＭＡＣモード）の使用によって、メッセージの完全性が維持される。本発明のテレメトリーセキュリティシステムでは、本明細書で論述するように、疑似乱数をその時々に生成しなければならない。乱数は、コンピュータ生成された数を指すとき、技術的に正確に言えば、コンピュータ生成された数が実際には決定的であるという点で、（真の乱数とは対照的に）いわゆる疑似乱数を指すことができる。しかしながら、疑似乱数は、全体関数（overall function）が、可観測にするために全体的に確率的プロセスとして振舞うように、好ましくは、十分に複雑な若しくは多様な状態又は補助関数から導出される。この数の実際の値は重要ではなく、特定の実施形態では、数は、暗号の種、メッセージ認証関数の種、さらには、別の疑似乱数生成の種として使用できることが理解されよう。数の実際の値は、疑似乱数の関数については重要ではないので、数の値は、任意であると言うことができる。任意とは、本明細書では、一般に「偶然」と同義であることが意図されている。一般に、本発明が、疑似乱数の使用をどこで必要としようとも、その機能は、たとえば、代替的な疑似乱数ジェネレータ、又は、本発明の代替的な実施形態によるハードウェア生成された乱数に置き換えることができる。特定の実施形態では、上述したＦＩＰＳ承認のＡＥＳブロック暗号仕様は、ＡＮＳＩ Ｘ９．３１仕様（付録Ａ．２．４）に基づくＮＩＳＴ推奨の疑似乱数ジェネレータ（ＰＲＮＧ）を実施したものを提供する。これは、本発明の典型的な実施形態に適している。ＡＮＳＩ Ｘ．９．３１ ＰＲＮＧ仕様のこの特定の実施形態は、ＡＥＳブロック暗号（ＦＩＰＳ ＰＵＢ １９７）を使用する。このタイプの実施形態は、一時に１２８ビットのＰＲＮＧ疑似乱数を生成する。   In order to open a communication session between nodes, an unsecured exchange is first performed between the communication devices, eg, by handshake, session request / acceptance, or other session initiation protocol. Preferably, the incoming packet length and outgoing packet length are fixed, and in particular embodiments according to the invention, the physical layer hardware is set up to predict these packet lengths. Thus, shorter or longer packets can be flagged as “bad” and rejected. The relevant cryptographic instance used must be available. One of various suitable encryption standards for use with the present invention is the FIPS approved 128-bit AES block cipher (FIPS PUB 197). Encryption can be appropriately performed in the “counter mode” (CTR mode) of AES. The freshness of the message can be checked through the use of a nonce (ie, a disposable pseudo-random number) such as a token. Also, in certain embodiments, message integrity is maintained, for example, through the use of AES “Cryptographic Block Chain Message Authentication Code Mode” (CBC-MAC mode). In the telemetry security system of the present invention, pseudorandom numbers must be generated from time to time, as discussed herein. Random numbers refer to computer-generated numbers, technically speaking, so-called pseudo-random numbers (as opposed to true random numbers) in that computer-generated numbers are actually decisive. Can be pointed to. However, the pseudorandom numbers are preferably derived from sufficiently complex or diverse states or auxiliary functions so that the overall function behaves as an overall stochastic process to make it observable. It will be appreciated that the actual value of this number is not critical, and in certain embodiments the number can be used as a cryptographic seed, a message authentication function seed, or even another pseudo-random number generation seed. Since the actual value of the number is not important for the pseudorandom function, it can be said that the value of the number is arbitrary. Arbitrary is generally intended herein to be synonymous with "accidental". In general, wherever the present invention requires the use of pseudo-random numbers, its functionality replaces, for example, an alternative pseudo-random number generator, or a hardware-generated random number according to alternative embodiments of the present invention. Can do. In certain embodiments, the FIPS-approved AES block cipher specification described above provides an implementation of the NIST recommended pseudo-random number generator (PRNG) based on the ANSI X9.31 specification (Appendix A.2.4). This is suitable for an exemplary embodiment of the present invention. ANSI X. This particular embodiment of the 9.31 PRNG specification uses an AES block cipher (FIPS PUB 197). This type of embodiment generates a 128-bit PRNG pseudorandom number at a time.

図６〜図９は、本発明の特定の実施形態による疑似乱数ジェネレータの機能のデータフロー図を示している。図６は、本発明の実施形態による、図９の乱数ジェネレータの最初のステップのデータフロー図を示している。特定の実施形態では、１２８ビット疑似乱数（ＰＲＮ）の生成は、ＡＮＳＩ Ｘ９．３１で指定されているように、ＡＥＳブロック暗号を使用して実施され、過度のオーバーヘッドなく、予測される攻撃者の処理能力の観点から十分なセキュリティ及びプライバシーを提供する。初期事項として、１２８ビット乱数ＫＲ６１０及びＲ０が、ＰＲＮＧに利用可能である。ＰＲＮＧキーであるＫＲ６１０は、変化せず、１２８ビットレジスタを経由してブロック暗号６２０のｋｅｙ＿ｉ入力６１５に常にロードされる。Ｒ０は、ＰＲＮＧが１２８ビット乱数を生成するごとに、新しい現在のＰＲＮ（Ｒ１，Ｒ２，…）で更新されるＰＲＮＧの秘密ランダム初期化ベクトル（secret and random initialization vector）である。ＫＲ６１０及び現在のＲの双方は、新しいいずれの疑似乱数の生成にも必要とされるので、メモリ又はセキュアローカルストレージに記憶することができる。 6-9 illustrate data flow diagrams of the functionality of a pseudo-random number generator according to certain embodiments of the invention. FIG. 6 shows a data flow diagram of the first step of the random number generator of FIG. 9, according to an embodiment of the present invention. In certain embodiments, 128-bit pseudo-random number (PRN) generation is performed using AES block ciphers, as specified in ANSI X9.31, and is anticipated for attackers without undue overhead. Provide sufficient security and privacy in terms of processing power. As an initial matter, 128-bit random numbers K R 610 and R 0 are available for PRNG. The PRNG key K R 610 does not change and is always loaded into the key_i input 615 of the block cipher 620 via a 128-bit register. R 0 is a PRNG secret and random initialization vector that is updated with a new current PRN (R 1 , R 2 ,...) Each time the PRNG generates a 128-bit random number. Since both K R 610 and the current R are needed to generate any new pseudo-random numbers, they can be stored in memory or secure local storage.

この実施形態では、あらゆる（ｉ＋１）番目のＰＲＮの生成は、次のように進行する。すなわち、図６に示すように、ブロック暗号６２０（この例では、１２８ビットＡＥＳ）が、キー入力６１５としてＫＲ６１０を使用してノンス６２５を暗号化するのに使用される。ノンス６２５は、たとえば、そのノードの現在のリアルタイムクロック値から構成することができ、１２８ビットレジスタを経由してブロック暗号６２０の１２８ビットｄａｔａ＿ｉ入力６３０にロードすることができる。（リアルタイムクロックが、１２８ビットよりも長い場合には、リアルタイムクロックの最下位１２８ビットを使用することができる。）リアルタイムクロックが１２８ビットよりも短い場合には、０の個数にリアルタイムクロックのビット数を加えたものが１２８に等しくなるように、ノンス６２５の最上位ビットを０でパッディングすることができる。リアルタイムクロックが、ノンス６２５を生成するのに使用されようとされまいと、ブロック暗号６２０から出力される中間値ｄａｔａ＿ｏ６３５は、本明細書では、Ｖ１６４０と呼ばれる場合がある。 In this embodiment, the generation of every (i + 1) th PRN proceeds as follows. That is, as shown in FIG. 6, a block cipher 620 (128 bits AES in this example) is used to encrypt the nonce 625 using K R 610 as the key input 615. The nonce 625 can, for example, consist of the current real-time clock value for that node and can be loaded into the 128-bit data_i input 630 of the block cipher 620 via a 128-bit register. (If the real-time clock is longer than 128 bits, the least significant 128 bits of the real-time clock can be used.) If the real-time clock is shorter than 128 bits, the number of bits of the real-time clock is zero. The most significant bit of nonce 625 can be padded with zeros so that the sum of is equal to 128. Whether or not the real-time clock is used to generate the nonce 625, the intermediate value data_o 635 output from the block cipher 620 may be referred to herein as V 1 640.

図７は、本発明による疑似乱数ジェネレータの一実施形態における図６のステップに続くステップを示している。図７に示すように、中間値Ｖ１６４０は、現在のＲ７１０（最初の乱数の場合はＲ０であり、（ｉ＋１）番目の乱数の場合はＲｉである）とＸＯＲされる。次に、この１２８ビット値 FIG. 7 illustrates steps following the step of FIG. 6 in one embodiment of a pseudo-random number generator according to the present invention. As shown in FIG. 7, the intermediate value V 1 640, the current R710 (in the case of the first random number is R 0, (i + 1) -th the case of random numbers is R i) is XOR with. Then this 128 bit value

Figure 2010507928
６２５をブロック暗号６２０で暗号化することができる。具体的には、ＫＲ６１０を、たとえば１２８ビットレジスタからブロック暗号６２０のｋｅｙ＿ｉ入力６１５にロードすることができる。それに続いて、
Figure 2010507928
 625 can be encrypted with block cipher 620. Specifically, K R 610 can be loaded into the key_i input 615 of the block cipher 620, eg, from a 128 bit register. Following that,

Figure 2010507928
６２５を、別の１２８ビットレジスタを経由してブロック暗号６２０のｄａｔａ＿ｉ入力６３０にロードすることができる。中間値Ｖ２７２０は、ブロック暗号６２０のｄａｔａ＿ｏ出力６３５である。
Figure 2010507928
 625 can be loaded into the data_i input 630 of the block cipher 620 via another 128-bit register. Intermediate value V 2 720 is a data_o output 635 of block cipher 620.

図８は、本発明による疑似乱数ジェネレータの一実施形態における図７のステップに続くステップを示している。この実施形態では、１２８ビット中間値Ｖ１６４０及びＶ２７２０が、互いにＸＯＲされ、ブロック暗号６２０で暗号化される。具体的には、ＫＲ６１０が、１２８ビットレジスタを経由してブロック暗号６２０のｋｅｙ＿ｉ入力６１５にロードされる。 FIG. 8 illustrates steps following the step of FIG. 7 in one embodiment of a pseudo-random number generator according to the present invention. In this embodiment, the 128-bit intermediate values V 1 640 and V 2 720 are XORed together and encrypted with the block cipher 620. Specifically, K R 610 is loaded into the key_i input 615 of the block cipher 620 via a 128-bit register.

Figure 2010507928
６２５の結果は、別の１２８ビットレジスタを経由してブロック暗号６２０のｄａｔａ＿ｉ６３０入力にロードされる。ブロック暗号６２０の出力ｄａｔａ＿ｏ６３５は、新しいＰＲＮ Ｒｉ＋１８１０を含む。さらなる１２８ビットＰＲＮが必要とされる場合には、新しいノンス６２５（たとえば、現在のリアルタイムクロックデータ）を使用し、且つ、新しく更新されたＰＲＮ Ｒｉ＋１８１０を使用して、ＲＮＧプロセスを繰り返すことができる。さらなる乱数が必要とされない場合、Ｒｉ＋１は、今後のセッションにおける今後のＰＲＮの生成に備えてメモリに記憶される。ＰＲＮＧキーＫＲ６１０は、メモリ又はセキュアローカルストレージに記憶することができる。
Figure 2010507928
 The result of 625 is loaded into the data_i 630 input of the block cipher 620 via another 128-bit register. The output data_o 635 of the block cipher 620 includes a new PRN R i + 1 810. If additional 128-bit PRN is needed, the RNG process may be repeated using a new nonce 625 (eg, current real-time clock data) and using the newly updated PRN R i + 1 810 it can. If no further random numbers are needed, R i + 1 is stored in memory for future PRN generation in future sessions. The PRNG key K R 610 can be stored in memory or secure local storage.

要約すれば、ＲＰＮＧキーの生成は、好ましくは、図９に示すように、次のように進行する。ブロック暗号が、関数Ｅ（ｄａｔａ＿ｉ；ｋｅｙ＿ｉ）＝ｄａｔａ＿ｏによって表され、ここで、Ｅが、関数への関連のある引数並びにｄａｔａ＿ｉ６３０及びｋｅｙ＿ｉ６１５（ｉ≧０を有する）を有するＡＥＳ関数６２０を表す場合、アルゴリズムは、ブロック暗号を通る３つのステップのネストされた処理又は反復的な処理に従って要約することができる。すなわち、
ステップ１．Ｖ１６４０＝Ｅ（ノンス６２５；ＫＲ６１０）
ステップ２． In summary, the generation of the RPNG key preferably proceeds as follows, as shown in FIG. If the block cipher is represented by a function E (data_i; key_i) = data_o, where E represents an AES function 620 with associated arguments to the function and data_i 630 and key_i 615 (with i ≧ 0), The algorithm can be summarized according to a three-step nested or iterative process through the block cipher. That is,
Step 1. V 1 640 = E (Nonce 625; K R 610)
Step 2.

Figure 2010507928
ステップ３．
Figure 2010507928
 Step 3.

Figure 2010507928
である。上記ステップの３つすべてを結合することによって、
Figure 2010507928
 It is. By combining all three of the above steps,

Figure 2010507928
が与えられる。
Figure 2010507928
 Is given.

本発明の特定の実施形態では、ＰＲＮ生成には、１２８ビットＡＥＳブロック暗号６２０及びモジュロ２加算機能の使用、ブロック暗号をバッファリングする３つの１２８ビットレジスタ、リアルタイムクロック又は別のノンス６２５のソースへのアクセス、並びに２つの１２８ビットの数Ｒｉ７１０及びＫＲ６１０のストレージ空間が割り当てられる。これらのうち、Ｒｉ及びＫＲのストレージ空間は、本発明の他の態様及び機能には利用可能でない場合がある。好ましくは、２つの１２８ビット乱数は、たとえば製造の際に、本発明のモジュールの実施態様に「インストール」することができる。これらの乱数のうちの一方（ＫＲ６１０）は、永久的なものとすることができ、他方Ｒ０７１０は、好ましくは、新しい疑似乱数が生成されるごとに、更新することができる。 In particular embodiments of the present invention, PRN generation uses a 128-bit AES block cipher 620 and modulo-2 add function, three 128-bit registers to buffer the block cipher, a real-time clock or another nonce 625 source. As well as two 128-bit numbers R i 710 and K R 610 storage space. Of these, the storage space of R i and K R, in addition to the aspects and features of the present invention may not be available. Preferably, the two 128-bit random numbers can be “installed” into the module embodiment of the present invention, eg, during manufacture. One of these random numbers (K R 610) can be permanent, while the other R 0 710 can preferably be updated each time a new pseudo-random number is generated.

本発明によるセキュアテレメトリーセッションは、好ましくは、１つ又は複数の通信デバイスがセキュアセッションを要求するといつでも開始される。セキュア通信セッションのセットアップは、２ステップのプロセスである。この２ステップのプロセスによって、すべての通信デバイスには、同じセッションキーＫｓｅｓが提供される。ステップ１において、すべての通信デバイスは、Ｒｘと呼ばれる事前に生成された疑似乱数、たとえば６４ビット乱数、を交代でアナウンスする。ここで、「ｘ」は、異なるデバイスをインデックスする。上述し且つ図６〜図９に示したように、特定の実施形態では、疑似乱数が次のセキュアセッションに直ちに利用可能であるように、疑似乱数は、前のセキュア通信セッションの終了時に生成される。これらの疑似乱数の生成は、好ましくは、本明細書の開示に従って行うことができるが、疑似乱数又はハードウェア生成された乱数を生成する他の方法を本発明に従って代用することもできる。   A secure telemetry session according to the present invention is preferably initiated whenever one or more communication devices request a secure session. Setting up a secure communication session is a two step process. This two-step process provides all communication devices with the same session key Kses. In step 1, all communication devices announce in turn a pre-generated pseudo-random number called Rx, for example a 64-bit random number. Here, “x” indexes different devices. As described above and illustrated in FIGS. 6-9, in certain embodiments, the pseudo-random number is generated at the end of the previous secure communication session so that the pseudo-random number is immediately available for the next secure session. The The generation of these pseudo-random numbers can preferably be performed according to the disclosure herein, but other methods of generating pseudo-random numbers or hardware-generated random numbers can be substituted according to the present invention.

事前に生成された乱数のアナウンスに続いて、次のステップは、セキュアセッションの確立を提供し、すべての通信デバイスが共通のセッションキー（Ｋｓｅｓ）を計算することを必要とする。この共通のセッションキーは、その後、セキュアセッションの継続時間の間、データトラフィックをセキュアにするのに使用される。Ｋｓｅｓは、独立に計算されるが、ブロック暗号等の暗号を使用して各デバイスによって全く同一に計算される。１２８ビットＡＥＳブロック暗号は、本発明の典型的な実施形態に適している。   Following the pre-generated random number announcement, the next step provides for the establishment of a secure session and requires all communication devices to calculate a common session key (Kses). This common session key is then used to secure the data traffic for the duration of the secure session. Kses is calculated independently, but is calculated exactly the same by each device using a cipher such as a block cipher. A 128-bit AES block cipher is suitable for an exemplary embodiment of the present invention.

図１０は、本発明の実施形態によるセッションキーの生成のデータフロー図である。共通セッションキーは、事前に確立されたＢＡＮキーＫＢＡＮ及び通信ノードの乱数のすべて｛Ｒ１，Ｒ２，Ｒ３…｝から導出することができる。特定の実施形態では、Ｋｓｅｓは、ブロック暗号６２０への「キー入力」６１５内にＫＢＡＮをロードし且つブロック暗号６２０の「データイン」６３０内にデバイスの乱数１０１０をロードすることによって計算することができる。これは、本発明の特定の実施形態では、ファームウェア制御によって成し遂げることができる。具体的には、最初の２つのデバイスの６４ビット乱数が連結されて１２８ビットの数にされる。次に、この１２８ビットの数が、ブロック暗号６２０の「データイン」６３０にロードされる。セキュアセッションを確立することを望むデバイスが２つしか存在しない場合、ブロック暗号６２０の１２８ビット出力６３５が、セッションキーＫｓｅｓとなる。単一のセッション内でセキュアに通信することを望むデバイスが３つ以上存在する場合、再びブロック暗号６２０の「データイン」６３０を入力して上述したように処理される前に、ブロック暗号６２０の出力６３５が、続いて、次の２つのデバイス１０２０の連結された１２８ビット（２×６４ビット）乱数にＸＯＲされる（すなわち、モジュロ２加算される）。暗号（ここでは、１２８ビットＡＥＳ）のＸＯＲ導出値６３５への適用は、好ましくは、デバイスの乱数のすべてを通過するのに必要な回数だけ繰り返される。ここで、ブロック暗号６２０の最終出力６３５は、Ｋｓｅｓ１０３０である。セキュアセッションに含まれるデバイスが奇数個存在する場合、１２８ビット連結の「空」のスロットを６４個の０で満たすことができる。セキュア通信セッションの終了時に、エフェメラル（ephemeral）Ｋｓｅｓ１０３０を「削除」することができ、新しい各セキュアテレメトリーセッションが提供されると、その開始時に、新しいセッションキー１０３０が計算される。 FIG. 10 is a data flow diagram of session key generation according to an embodiment of the present invention. The common session key can be derived from the previously established BAN key K BAN and all of the communication node random numbers {R 1 , R 2 , R 3 . In certain embodiments, Kses is calculated by loading K BAN into “key input” 615 to block cipher 620 and device random number 1010 into “data in” 630 of block cipher 620. Can do. This can be accomplished by firmware control in certain embodiments of the invention. Specifically, the 64-bit random numbers of the first two devices are concatenated into a 128-bit number. This 128-bit number is then loaded into the “data in” 630 of the block cipher 620. If there are only two devices that want to establish a secure session, the 128-bit output 635 of the block cipher 620 becomes the session key Kses. If there are more than two devices that wish to communicate securely within a single session, the block cipher 620's “data in” 630 is again entered before being processed as described above. The output 635 is then XORed (ie, modulo 2 added) to the concatenated 128 bit (2 × 64 bit) random number of the next two devices 1020. The application of the cipher (here 128-bit AES) to the XOR derived value 635 is preferably repeated as many times as necessary to pass all of the device random numbers. Here, the final output 635 of the block cipher 620 is Kses1030. If there are an odd number of devices included in a secure session, a “empty” slot of 128-bit concatenation can be filled with 64 zeros. At the end of the secure communication session, the ephemeral Kses 1030 can be “deleted”, and as each new secure telemetry session is provided, a new session key 1030 is calculated at the start.

説明したように、特定の実施形態で情報をセキュアにすることは、たとえばカウンタ（ＣＴＲ）モードで使用されるブロック暗号が使用されることを含めて、暗号に基づくことができる。このように、ブロック暗号は、キー付き疑似乱数キーストリームを生成するという点で、ストリームに適用することができる（又は、受信側ノードにおいて、平文を生成して解読を行うために暗号文に対して適用することができる）。このキー付き疑似乱数キーストリームは、その後、暗号化文を生成するために平文に対してＸＯＲされる。図１１は、本発明の実施形態によるメッセージのＣＴＲモードの暗号及び解読のデータフローを示している。図示するように、共有セッションキー１０３０は、１２８ビットレジスタを経由してブロック暗号６２０のｋｅｙ＿ｉ入力６１５にロードされ、セッションキー１０３０は、（上述したように、セキュアセッションの開始時に計算された後）メモリ又はストレージからレジスタにロードすることができる。１２８ビットノンス（すなわち、１回だけ使用される数）１１１０は、別の１２８ビットレジスタを経由して、ブロック暗号６２０のｄａｔａ＿ｉ入力６３０にロードされる。   As described, securing information in certain embodiments can be based on cryptography, including, for example, using block ciphers used in counter (CTR) mode. Thus, the block cipher can be applied to the stream in that it generates a keyed pseudo-random key stream (or it can be applied to the ciphertext to generate plaintext and decrypt it at the receiving node). Can be applied). This keyed pseudo-random key stream is then XOR'd against the plaintext to generate an encrypted text. FIG. 11 illustrates a CTR mode encryption and decryption data flow of a message according to an embodiment of the present invention. As shown, the shared session key 1030 is loaded into the key_i input 615 of the block cipher 620 via a 128-bit register and the session key 1030 is (after being calculated at the start of the secure session, as described above). It can be loaded into registers from memory or storage. The 128-bit nonce (ie, a number that is used only once) 1110 is loaded into the data_i input 630 of the block cipher 620 via another 128-bit register.

図１２は、本発明の実施形態によるノンスレジスタのデータ構造を示している。この実施形態では、図１２に示すように、１２８ビットノンス１１１０の最上位８バイト１２１０が、実際には、８バイトのアップカウンタ１２１０である一方、そのカウンタの下位側の６バイト１２１５は、インスティゲーティングデバイス（instigating device）の乱数Ｒｘ１２２０の最下位６バイト［すなわち、ビット４７〜ビット０］で開始される。乱数Ｒｘ１２２０は、図１０のセッションキー１０３０の生成に貢献されたものであることが理解されよう。本発明によるテレメトリーパケットが、セキュアセッションで受信又は送信されるごとに、カウンタ１２１０の値がインクリメントされる。（８バイトカウンタ１２２０のすぐ下の）次のノンスバイト１２２５は、図１２のビット「ｍ」１２３０であるモードビット１２３０を含む。本明細書で説明するように、このビットは、ノンスがＣＴＲモード暗号化／解読に使用されているときは、論理０に設定することができ、ノンスがメッセージの完全性に使用されているときは、モードビットは論理１に設定される。モードビットの下の７ビットフィールドであるブロック番号フィールド１２４０は、あらゆるパケットの開始時に論理０００００００にリセットされ、そのパケット内の暗号化／解読に使用されるキーストリームマテリアルの各１２８ビットブロックの生成時にインクリメントされる。たとえば、各テレメトリーパケットが、暗号化／解読に３００ビットのキーストリームマテリアルを必要とした場合、キーストリームの最初の１２８ビットは、０００００００を使用して生成され、２番目の１２８ビットは、００００００１を使用して生成され、３番目の１２８ビットは、０００００１０を使用して生成される（１つずつインクリメントされる。キーストリームマテリアルの３００ビットがパケットごとに必要とされる例では、キーストリームマテリアルの最後の１２８ビットのうちの４４ビットのみが必要とされることに留意する）。１２８ビットノンス１１１０の残りの７バイト（最下位７バイト１２４０）は、好ましくは、永久的に論理０に設定することができる。   FIG. 12 shows a data structure of a nonce register according to an embodiment of the present invention. In this embodiment, as shown in FIG. 12, the most significant 8 bytes 1210 of the 128-bit nonce 1110 is actually an 8-byte up counter 1210, while the lower 6 bytes 1215 of the counter are It starts with the least significant 6 bytes of the random number Rx1220 [ie bit 47 to bit 0] of the instigating device. It will be appreciated that the random number Rx 1220 was contributed to the generation of the session key 1030 of FIG. Each time a telemetry packet according to the present invention is received or transmitted in a secure session, the value of the counter 1210 is incremented. The next nonce byte 1225 (just below the 8-byte counter 1220) includes a mode bit 1230, which is bit “m” 1230 in FIG. As described herein, this bit can be set to logical 0 when a nonce is used for CTR mode encryption / decryption and when a nonce is used for message integrity. The mode bit is set to logic one. The block number field 1240, which is a 7-bit field below the mode bits, is reset to logic 0000000 at the beginning of every packet, and upon generation of each 128-bit block of keystream material used for encryption / decryption within that packet. Incremented. For example, if each telemetry packet requires 300 bits of keystream material for encryption / decryption, the first 128 bits of the keystream are generated using 0000000 and the second 128 bits are 0000001. The third 128 bits are generated using 0000010 (incremented by one. In an example where 300 bits of keystream material are required per packet, the keystream material Note that only 44 of the last 128 bits are required). The remaining 7 bytes (least significant 7 bytes 1240) of the 128-bit nonce 1110 can preferably be set to logic 0 permanently.

反射攻撃を防止することを助ける同期されたタイムスタンプではなく、又は、このタイムスタンプに加えて、本発明の特定の実施形態では、あらゆるセキュアテレメトリックセッションの開始時に新しいセッションキーＫｓｅｓ１０３０を計算することによって、メッセージの新しさ及びユーザ認証が提供される。この新しいセッションキー１０３０は、セキュアセッションの参加者のそれぞれによって生成された乱数の貢献度（contribution）の関数である。しかしながら、セッション内の反射攻撃について、さらなる新しさのメカニズムを提供することができる。この場合、セキュアセッションのデバイスは、セッションノンスの自身のローカルコピーにおけるカウンタを、その現在の値よりも小さな値にリセットすることを決して可能にすべきでない。テレメトリー通信セッションが中断されるか、又は、他の或る理由から、基礎となる通信プロトコル内で「リセット」若しくは再同期する必要がある場合、セキュアセッションのデバイスが再同期するために、現在のセッションノンスはアナウンスされることが必要な場合がある。攻撃者は、おそらく、他のセッション参加者のノンスを前の値にリセットし、それによって、攻撃者が、前のノンス値を使用した古いメッセージを反射できるように試みることによって、このような状況の悪用を企てている可能性がある。このように、セッションノンスは、かなりのネットワークトークンとして機能する。ノンスカウンタが増加のみ行う場合、２６４個を超えるパケットが単一のセキュアセッションで通信されることはないという条件で、過去のセッション内メッセージは、以前のノンスを有するので、古いメッセージは、決して正当なノンスを有しない。なお、２６４個を超えるパケットが単一のセキュアセッションで通信されることは、起こりそうもないことである。 Not a synchronized timestamp that helps prevent replay attacks, or in addition to this timestamp, certain embodiments of the present invention calculate a new session key Kses 1030 at the start of every secure telemetric session. Provides message freshness and user authentication. This new session key 1030 is a function of the contribution of random numbers generated by each of the participants in the secure session. However, additional novelty mechanisms can be provided for replay attacks within a session. In this case, the device of the secure session should never be able to reset the counter in its local copy of the session nonce to a value smaller than its current value. If a telemetry communication session is interrupted or needs to be “reset” or re-synchronized within the underlying communication protocol for some other reason, Session nonces may need to be announced. The attacker would probably reset the other session participant's nonce to the previous value, thereby allowing the attacker to attempt to reflect old messages that used the previous nonce value. May be attempting to misuse. Thus, the session nonce functions as a considerable network token. If nonce counter performs only increase, on condition that a packet of more than 2 64 will not be communicated in a single secure session, past sessions in a message, because it has a previous nonce, old messages, never Does not have a valid nonce. Incidentally, the packets that exceed the 2 64 is communicated in a single secure session is nor unlikely.

図１１に示すように、本発明の実施形態では、暗号化及び解読は、好ましくは、ブロック暗号６２０の１２８ビット出力バスｄａｔａ＿ｏ６３５と、暗号化用のペイロード平文から取られた１２８ビットデータブロック１１１５、及び、解読用のペイロード暗号文から取られた１２８ビットデータブロック１１１５との間でビット単位のモジュロ２加算（ＸＯＲ）を実行することによって行われる。本発明の特定の実施形態では、パケットヘッダは暗号化されない。   As shown in FIG. 11, in the embodiment of the present invention, the encryption and decryption is preferably performed by the 128-bit output bus data_o 635 of the block cipher 620 and the 128-bit data block 1115 taken from the plaintext payload for encryption. And by performing bitwise modulo-2 addition (XOR) with the 128-bit data block 1115 taken from the decrypted payload ciphertext. In certain embodiments of the invention, the packet header is not encrypted.

図１３は、本発明の一実施形態によるテレメトリーパケット１３００のデータ構造を示している。１２８ビットメッセージブロック１１１５のそれぞれは、ブロック暗号６２０の異なる出力６３５とＸＯＲ１１２０を行うことができる。たとえば、図１３のメッセージブロックｍ１１３１０は、キーストリームブロック（すなわち、ブロック暗号６２０のｄａｔａ＿ｏバス６３５を残した１２８ビットブロック）ｓ１とＸＯＲされ、メッセージブロックｍ２（パケットの次の１２８ビット１３２０）は、ｓ２とＸＯＲされる。他のメッセージブロックについても同様にＸＯＲされる。前述したように、異なるノンス１１１０は、各キーストリームブロック６３５の生成で使用される。特定の実施形態では、同じノンス１１１０が、同じセッション内で２回使用されることは決してない。したがって、８バイトノンスカウンタ１２１０が、その最大値（０ｘｈＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ）に達すると、セキュアセッションを終了することができ、新しいセッションキーが一括して計算される。この実施形態では、単一のセッションキーを使用して通信できるテレメトリーパケットの個数は、２６４個（インスティゲータ（instigator）の乱数の最下位６バイトが０ｘｈ００００００００００００である場合に対応する）から２６４−２４８個（インスティゲータの乱数の最下位６バイトが０ｘｈＦＦＦＦＦＦＦＦＦＦＦＦの場合に対応する）である。１０進数では、これらの数は、それぞれ１．８４４６７×１０１９及び１．８４４６４×１０１９であり、したがって、実際にこれらのパケット数に決して達する可能性がないことが理解されよう。 FIG. 13 shows a data structure of a telemetry packet 1300 according to an embodiment of the present invention. Each 128-bit message block 1115 can perform a different output 635 and XOR 1120 of the block cipher 620. For example, message block m 1 1310 in FIG. 13 is XORed with key stream block (ie, 128 bit block leaving data_o bus 635 of block cipher 620) s 1 and message block m 2 (the next 128 bits 1320 of the packet). ) Is XORed with s 2 . The other message blocks are similarly XORed. As described above, a different nonce 1110 is used in the generation of each keystream block 635. In certain embodiments, the same nonce 1110 is never used twice in the same session. Therefore, when the 8-byte nonce counter 1210 reaches its maximum value (0xhFFFFFFFFFFFFFFFF), the secure session can be terminated and a new session key is calculated in a lump. In this embodiment, the number of telemetry packets that can be communicated using a single session key is from 2 64 (corresponding to the case where the least significant 6 bytes of the random number of the instigator is 0xh000000000000) to 2 64 −2 48 (corresponding to the case where the least significant 6 bytes of the random number of the instigator is 0xhFFFFFFFFFFFF). In decimal numbers, it will be appreciated that these numbers are 1.84467 × 10 19 and 1.84464 × 10 19 respectively , and therefore, these packet numbers may never actually be reached.

たとえばＴＤＭＡ構造といったセキュアにされたネットワークでは、好ましくは、デバイスは、非送信の期間中にセキュアな通信を維持するために、そのデバイスが、自身に割り当てられた窓の期間中に実際にブロードキャストするか否かにかかわらず、自身のノンスカウンタをインクリメントする。この非送信の時間の間、デバイスは、エネルギーを保存するために自身の無線の電源を切ることができる。電源投入時に、デバイスは、セッションノンスの経過を追跡してきており、依然として、後に電源投入することができ、セキュアに通信することができる。代替的に、テレメトリーネットワークセッションの「マスタ」又は「ビーコン」は、ネットワークセッション内で新しい「ラウンド」を開始するごとに、現在のノンスカウンタをセキュアにせずにブロードキャストすることができる。   In a secured network, eg, a TDMA structure, preferably the device broadcasts during the window assigned to it to maintain secure communications during non-transmission periods. Regardless of whether or not, it increments its nonce counter. During this non-transmission time, the device can turn off its radio to conserve energy. At power up, the device has tracked the progress of the session nonce and can still be powered on later and communicate securely. Alternatively, the “master” or “beacon” of a telemetry network session can broadcast the current nonce counter without making it secure each time it initiates a new “round” within the network session.

本発明の特定の実施形態では、ＭＡＣは、各テレメトリーパケットについて計算され、各テレメトリーパケットにアペンドされる。また、本発明の特定の実施形態では、１つのパケットサイズ及びパケット構造が使用される。このようなパケット構造の１つの可能な実施形態が、図１３に示されている。図示するように、本発明によるパケット１３００は、４２ビット（５．２５バイト）ヘッダ１３１０、３０バイトペイロード１３１５、及び３バイトＭＡＣ１３２０から構成することができる。   In certain embodiments of the invention, the MAC is calculated for each telemetry packet and appended to each telemetry packet. Also, in certain embodiments of the invention, a single packet size and packet structure is used. One possible embodiment of such a packet structure is shown in FIG. As shown, a packet 1300 according to the present invention can be composed of a 42-bit (5.25 byte) header 1310, a 30-byte payload 1315, and a 3-byte MAC 1320.

本発明の特定の実施形態では、ブロック暗号（たとえば、１２８ビットＡＥＳ）をＣＢＣ−ＭＡＣモードで使用して、メッセージの平文のキー付きハッシュ値（メッセージ認証コード、すなわちＭＡＣ）を生成することができる。このキー付きハッシュ値は、図１３に示すように、１３２０において、送信時にそのメッセージ１３１５の暗号化された形態にアペンドされる。これらのパケット１３００及びそれにアペンドされたＭＡＣ１３２０を受信すると、受信機は、パケットペイロード１３１５を解読し、それらの解読されたパケットに関するＭＡＣを計算し、受信機は受信されたペイロード１３１５から導出した、計算されたＭＡＣ値を、本パケット１３００にアペンドされて受信されたＭＡＣ値１３２０と比較する。これらのＭＡＣが一致した場合、パケット１３００は受理される。当然、ＭＡＣが矛盾した場合、パケット１３００は廃棄又は再要求される。ＭＡＣ１３２０が、本発明に従って計算され、各パケット１３１５にアペンドされる場合、従来技術のテレメトリーシステムにおけるパケットごとのＣＲＣの代わりにＭＡＣ１３２０を使用することができる。本明細書でさまざまに詳述したように、特定のパケットがセキュアにされずに送信される限りにおいて、付加的に、（ＣＲＣのような）キー付きでない（unkeyed）完全性チェックメカニズムを適用することができる。この完全性チェックは、ハードウェアＣＲＣの使用を通じて実現することもできるし、代替的に、公に知られたキー及びノンスを有するＣＢＣ−ＭＡＣを使用することによって（たとえば、双方について０ｘ００００００００００００００００００００００００００００００００を使用することによって）実現することもできる。   In certain embodiments of the invention, a block cipher (eg, 128-bit AES) may be used in CBC-MAC mode to generate a plaintext keyed hash value (message authentication code, or MAC) of the message. . This keyed hash value is appended at 1320 to the encrypted form of the message 1315 at the time of transmission, as shown in FIG. Upon receipt of these packets 1300 and the MAC 1320 appended thereto, the receiver decrypts the packet payload 1315 and calculates the MAC for those decrypted packets, and the receiver derives from the received payload 1315 The MAC value is compared with the MAC value 1320 that is appended to the packet 1300 and received. If these MACs match, the packet 1300 is accepted. Of course, if the MAC is inconsistent, the packet 1300 is discarded or re-requested. If a MAC 1320 is calculated according to the present invention and appended to each packet 1315, the MAC 1320 can be used instead of a per-packet CRC in prior art telemetry systems. As variously detailed herein, in addition, an unkeyed integrity check mechanism (such as a CRC) is applied as long as a particular packet is transmitted unsecured. be able to. This integrity check can be achieved through the use of a hardware CRC, or alternatively by using a CBC-MAC with a publicly known key and nonce (eg, using 0x00000000000000000000000000000000 for both) Can also be realized.

ＭＡＣ１３２０を使用するこの実施形態では、パケットペイロード１３１５（すなわち、暗号化されるパケットの部分）の長さは３０バイトである（したがって、１ビットのみのノンスレジスタブロック番号フィールド１２３５を必要とする）が、ノンスレジスタブロック番号フィールド１２３５は、同じノンスレジスタ構造１１１０を使用して、４０９６バイトと同じ長さのより長いパケットペイロードの使用を可能にすることができる将来のテレメトリー方式に備えて７ビットに固定することができる。   In this embodiment using the MAC 1320, the packet payload 1315 (ie, the portion of the packet to be encrypted) is 30 bytes in length (thus requiring a 1-bit nonce register block number field 1235). The nonce register block number field 1235 is fixed to 7 bits for future telemetry schemes that can use longer packet payloads as long as 4096 bytes using the same nonce register structure 1110. can do.

図１４に示す本発明の代表的な一実施形態によるＣＢＣ−ＭＡＣ生成／検証アルゴリズムでは、最初に、共有セッションキー１０３０（ＣＴＲモード暗号化／解読に使用されるものと同じもの）が、１２８ビットレジスタ１４３０を経由してブロック暗号６２０のｋｅｙ＿ｉ入力６１５にロードされる。ブロック暗号６２０のｄａｔａ＿ｉ入力６１５には、ノンスの９７ビットの最上位ビット（必要に応じて、ブロック番号フィールドをトランケートする）と最大で最初の３１ビットまでの平文パケットのビット（通常はヘッダ情報から成る）とを連結したもの１４３５をロードすることができる。ノンスレジスタ１１１０のモードビット１２３０は、論理１に設定することができる。典型的な実施形態では、ＣＢＣ−ＭＡＣアルゴリズムがＭＡＣ生成に使用されているのかＭＡＣ検証に使用されているのかにかかわらず、ＣＢＣ−ＭＡＣ処理は、各パケットの解読された形態（すなわち、メッセージ平文）に対して行われる。この実施形態では、したがって、受信されたパケットは、それらのパケットのＭＡＣが検証可能になる前に、解読されなければならない。   In the CBC-MAC generation / verification algorithm according to an exemplary embodiment of the present invention shown in FIG. 14, the shared session key 1030 (same as that used for CTR mode encryption / decryption) is first 128 bits. The data is loaded into the key_i input 615 of the block cipher 620 via the register 1430. The data_i input 615 of the block cipher 620 includes a nonce's 97 most significant bits (truncating the block number field if necessary) and plaintext packet bits up to the first 31 bits (usually from header information). 1435 can be loaded. The mode bit 1230 of the nonce register 1110 can be set to logic one. In an exemplary embodiment, regardless of whether the CBC-MAC algorithm is used for MAC generation or MAC verification, the CBC-MAC processing is performed in the decrypted form of each packet (ie, the message plaintext). ). In this embodiment, therefore, received packets must be decrypted before their MAC can be verified.

図１４の最初のブロック暗号６２０の出力（ｄａｔａ＿ｏ）６３５は、１４３５における９７ビットノンスに連結された平文に続く次の１２８ビットとビット単位でＸＯＲすることができる。次に、このＸＯＲの結果は、第２のブロック暗号１４４０の入力６３０にロードされる。次に、第２のブロック暗号１４４０の出力６３５は、パケット１３００の１３１５からのパケット平文の最後の１２８ビット（必要に応じて０がパッディングされる）とＸＯＲされ、次いで、第３のブロック暗号１４４５によって処理される。この実施形態では、パケットヘッダ及びパケットペイロードのビット合計が２８７ビット以下であるので、ＭＡＣが、第３のブロックの１２８ビット出力（ｄａｔａ＿ｏ）であることから、ＣＢＣ−ＭＡＣのラウンドはそれ以上必要とされない。ＭＡＣが、本発明の代替的な一実施形態に従って、より長いパケットに対して必要とされる場合、出力をＸＯＲしてさらなるブロック暗号６２０に通すことによって、さらなる平文ブロックを処理することができる。一般に、ｍ個のブロックの平文について、ｍ回のＸＯＲ／ブロック暗号ラウンド６３０が必要とされる。ここで、最後のブロック暗号のｄａｔａ＿ｏ出力６３５がＭＡＣ１４５０となる。図１４には、３つのブロック暗号コア６２０、１４４０、１４４５が示されているが、特定の実施形態では、１つのコアしか実際にハードウェアで実施されず、実際には、ＸＯＲ出力は、第１のブロック暗号６２０のｄａｔａ＿ｉ入力６３０へ送られることに留意されたい。図１４に示す３つのコア６２０、１４４０、１４４５は、ＣＢＣ−ＭＡＣアルゴリズムを例示するようにのみ意図されている。   The output (data_o) 635 of the first block cipher 620 of FIG. 14 can be XORed bit by bit with the next 128 bits following the plaintext concatenated with the 97-bit nonce in 1435. This XOR result is then loaded into the input 630 of the second block cipher 1440. Next, the output 635 of the second block cipher 1440 is XOR'd with the last 128 bits of the packet plaintext from packet 1300 1315 (padded with 0 if necessary) and then the third block cipher Processed by 1445. In this embodiment, since the total bit of the packet header and the packet payload is 287 bits or less, since the MAC is the 128-bit output (data_o) of the third block, more rounds of CBC-MAC are required. Not. If the MAC is needed for longer packets, according to an alternative embodiment of the invention, further plaintext blocks can be processed by XORing the output through additional block cipher 620. Generally, for X plaintexts of m blocks, m XOR / block cipher rounds 630 are required. Here, the data_o output 635 of the last block cipher becomes the MAC 1450. FIG. 14 shows three block cipher cores 620, 1440, 1445, but in certain embodiments, only one core is actually implemented in hardware, and in practice the XOR output is Note that one block cipher 620 is sent to the data_i input 630. The three cores 620, 1440, 1445 shown in FIG. 14 are intended only to illustrate the CBC-MAC algorithm.

図１４に示すように、本発明の特定の実施形態では、ＣＢＣ−ＭＡＣ出力１４５０の最下位２４ビット（ビット２３〜ビット０）のみが、処理されたパケット１３００の最後にＭＡＣ１３２０としてアペンドされる。これによって、ＣＢＣ−ＭＡＣ関数（この場合、１２８ビット）の基礎となる暗号強度は危険にさらされない。   As shown in FIG. 14, in a particular embodiment of the present invention, only the least significant 24 bits (bit 23 to bit 0) of the CBC-MAC output 1450 are appended as MAC 1320 at the end of the processed packet 1300. Thereby, the cryptographic strength underlying the CBC-MAC function (in this case 128 bits) is not compromised.

セキュアにされたセッションに参加する各デバイスは、好ましくは、あらゆるパケット１３３０の送信時及び受信時に自身の各セッションノンスカウンタ１２１０をインクリメントする。このように、一時にセキュアセッションの１つのデバイスしか送信していないので、ノンスインクリメントは、プロキシトークンとして機能し、したがって、複数のデバイスを同時に送信できないことが確実にされる。特定の実施形態では、テレメトリーパケットは比較的長いので、ノードは、特定の状況で、ＢＡＮグループの中でノンス同期を場合によっては喪失する可能性がある。基礎となる通信プロトコルによってサポートされる場合、本発明の特定の実施形態では、デバイスは、自身の現在の平文ノンスをフレームヘッダに定期的に含めて、ノンス同期チェックを提供することができる。典型的な実施形態では、ノンス同期は、一般に、現在のノンス１１１０をＮＡＣＫパケットに常に含めることによって回復することもできるし、基礎となる通信プロトコルに存在するネイティブ回復技法が何であってもそれを通じて回復することもできる。好ましくは、本明細書でさらに説明するように、すべてのデバイスは、ａ）セッションノンスのデバイスのコピー内のカウンタが、デバイスがメンテナンスメッセージで受信するあらゆるノンスと少なくとも同程度の大きさであるべきであるというルール、及び、ｂ）ノンスカウンタが０ｘｈＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦに達すると、新しいセッションキーを計算しなければならないというルール、に従い、ノンスは、２回使用されることはなく、したがって、メッセージの新しさが保証される。   Each device participating in a secured session preferably increments its respective session nonce counter 1210 upon transmission and reception of every packet 1330. Thus, since only one device of a secure session is transmitting at a time, the nonce increment functions as a proxy token, thus ensuring that multiple devices cannot be transmitted simultaneously. In certain embodiments, telemetry packets are relatively long, so a node can potentially lose nonce synchronization within a BAN group in certain circumstances. If supported by the underlying communication protocol, in certain embodiments of the invention, the device may periodically include its current plaintext nonce in the frame header to provide a nonce synchronization check. In an exemplary embodiment, nonce synchronization can generally be recovered by always including the current nonce 1110 in the NACK packet, and through whatever native recovery technique exists in the underlying communication protocol. It can also be recovered. Preferably, as further described herein, all devices should: a) the counter in the device copy of the session nonce should be at least as large as any nonce that the device receives in the maintenance message B) and the rule that a new session key must be calculated when the nonce counter reaches 0xhFFFFFFFFFFFFFFFF, the nonce is never used twice, so the newness of the message Guaranteed.

好ましくは、暗号化／解読は、ヘッダ１３１０ではなく、テレメトリーパケットペイロード１３１５に適用されるべきである。本発明のこの実施形態は、攻撃者に利用可能な既知の平文及び必要とされるキーストリームの長さの双方を最小にする傾向がある。さらに、これによって、パケットヘッダ１３１０が物理レイヤハードウェアを通じて伝播している間に、キーストリームマテリアルを計算してバッファリングするブロック暗号時間が与えられる。本発明の特定の実施形態では、単一のブロック暗号コア６２０（たとえば、ＡＥＳブロック暗号）は、暗号化関数及びＭＡＣ関数の双方を実施するのに使用されるが、これは、好ましくは、ランタイムにブロックごとにＣＴＲモードをＣＢＣ−ＭＡＣモードと交互に用いるのではなく、最初に、パケット全体のペイロードデータ１３１５の分量について、ＣＲＴモードを使用して十分なキーストリームマテリアルを生成して記憶することによって行われる。暗号化／解読された１２８ビットブロックが利用可能になると、ＣＢＣ−ＭＡＣモードを使用して、引き続きＭＡＣが生成／検証される。図１５は、本発明の一実施形態によるパケット（３２バイト以下のペイロード）のＣＴＲモード及びＣＢＣ−ＭＡＣモードのＡＥＳベースの混合使用について提案されたハードウェアレイアウトを示している。   Preferably, encryption / decryption should be applied to the telemetry packet payload 1315, not the header 1310. This embodiment of the invention tends to minimize both the known plaintext available to the attacker and the required keystream length. In addition, this provides block cipher time to compute and buffer keystream material while the packet header 1310 is propagated through the physical layer hardware. In certain embodiments of the invention, a single block cipher core 620 (eg, AES block cipher) is used to implement both the encryption function and the MAC function, which is preferably run-time Instead of using CTR mode alternately with CBC-MAC mode on a block-by-block basis, first generate and store sufficient keystream material using CRT mode for the amount of payload data 1315 for the entire packet. Is done by. Once the encrypted / decrypted 128-bit block is available, the MAC is subsequently generated / verified using CBC-MAC mode. FIG. 15 shows a proposed hardware layout for AES-based mixed use of CTR mode and CBC-MAC mode of packets (payloads of 32 bytes or less) according to an embodiment of the present invention.

一般に、本発明によるノードの一ハードウェア実施態様は、１２８ビットＡＥＳブロック暗号の１つのインスタンス（及び対応する専用の１２８ビットレジスタ）と、１２８ビットＢＡＮキー用のキープアライブストレージ又は不揮発性ストレージとを必要とする。セッションノンスは、セッションキー（Ｒｘ）へのインスティゲーティングデバイスの乱数の貢献のみから成るので、セキュアにされたネットワークのすべてのデバイスは、さらなる送信を行う必要なく、セッションノンスを知っている。図１５に示すように、単一のブロック暗号６２０を使用して、ｄａｔａ＿ｉ入力６３０に対する（入力１５１０を介した）キーストリーム又は（入力１５１５を介した）ＣＢＣ−ＭＡＣ入力のいずれかが処理される。ブロック暗号６２０の出力６３５であるレジスタ１５１５は、平文１５２５とＸＯＲされて、平文データ１５２５が暗号化される。   In general, one hardware implementation of a node according to the present invention comprises one instance of a 128-bit AES block cipher (and a corresponding dedicated 128-bit register) and keep-alive or non-volatile storage for a 128-bit BAN key. I need. Since the session nonce consists only of the random number of the initiating device to the session key (Rx), all devices in the secured network know the session nonce without having to make further transmissions. As shown in FIG. 15, a single block cipher 620 is used to process either the key stream (via input 1510) or the CBC-MAC input (via input 1515) to the data_i input 630. . The register 1515 that is the output 635 of the block cipher 620 is XORed with the plaintext 1525 to encrypt the plaintext data 1525.

本発明の特定の実施形態では、（セッションをオープンし、乱数を共有するのに使用されるパケットのように）パケットをセキュアにせずに通信する必要がある限りにおいて、キー付きでない完全性チェックが依然として使用される。この完全性チェックは、たとえば、ハードウェアＣＲＣの使用を通じて実施することもできるし、（双方について０ｘ００００００００００００００００００００００００００００００００のような）おそらく、公に知られた秘密キー及びノンスを有するＣＢＣ−ＭＡＣを使用することによって実施することもできる。   In certain embodiments of the invention, as long as the packets need to be communicated unsecured (such as packets used to open sessions and share random numbers), unkeyed integrity checks Still used. This integrity check can be performed, for example, through the use of a hardware CRC, possibly by using a CBC-MAC with a publicly known secret key and nonce (such as 0x00000000000000000000000000 for both). It can also be implemented.

キーストリームマテリアルが生成され、第１のキーストリームレジスタ１５１０及び第２のキーストリームレジスタ１５１５にそれぞれ記憶される。第２のキーストリーム１５１５レジスタのキーストリームマテリアルが使い切られると、第１のキーストリームレジスタ１５１０が、キーストリームレジスタ１５１５に並行してロードされる。第１の平文ブロックは、レジスタ１５２０に記憶され、（第１のキーストリームレジスタ１５１０のキーストリームマテリアルが、第２のキーストリームレジスタ１５１５に移されると）ブロック暗号処理６２０に続く結果の第１のＭＡＣブロックが、第１のキーストリームレジスタ１５１０に記憶される。第１のＭＡＣブロックは、１５２５からの平文の第２のブロックとＸＯＲされ、ブロック暗号６２０に通される。次に、最後のＭＡＣ１５３０の最下位２４ビットが、図１３の暗号化されたデータ１３１５にアペンドされる。   Keystream material is generated and stored in first keystream register 1510 and second keystream register 1515, respectively. When the keystream material in the second keystream 1515 register is used up, the first keystream register 1510 is loaded into the keystream register 1515 in parallel. The first plaintext block is stored in register 1520 and the first of the results following block cipher processing 620 (when the keystream material in first keystream register 1510 is moved to second keystream register 1515). The MAC block is stored in the first key stream register 1510. The first MAC block is XOR'ed with the plaintext second block from 1525 and passed through the block cipher 620. Next, the least significant 24 bits of the last MAC 1530 are appended to the encrypted data 1315 of FIG.

本発明による無線テレメトリーシステムでは、本明細書で開示したように、通常、体内デバイスと体外デバイスとの間の通信セッションを完全に無線で開始、実行、及びクローズすることができる。したがって、論述したように、認可されていない且つ／又は悪意のある関係者が、埋め込まれたデバイス又はＢＡＮの他のノードと通信することを防止することが重要である。しかしながら、実際には、認可されていない体外デバイス（医師プログラマ器具、緊急対応機器等）及びそのユーザ（これらのユーザは、埋め込み物の秘密キーにアクセスできないという意味で認可されていないが、患者のＢＡＮにアクセスする患者の明白な又は暗黙の同意又は指示を有する）が、それにもかかわらず、埋め込まれたデバイスと通信することが必要な状況が発生し得ることが理解されよう。このような状況は、たとえば、埋め込み物自体によって引き起こされていようがいまいが、患者が危機的な事象、さらには、命に関わる生理学的事象を受けている緊急の状況で発生し得る。たとえば、患者は、おそらく意識不明であり、識別マテリアルを有しない場合がある。また、上記プロトコルによる認証が禁止されているか又は実現不可能である過度の不便さのために、上述したような本発明の態様におけるフル認証が実現可能でない状況も発生し得る。たとえば、患者は、医師と会うための予約で大きな距離を移動してきた場合があるが、到着した時に、自身のスマートカード、又は、体外ノードが埋め込み物と通信できるようにするのに必要な他のマテリアルを忘れてきた又は置き忘れてきたことに気付く場合もあるし、患者は、自身の認証パスワードを忘れてしまっている場合もある。これらの状況では、「バックドア」、すなわち、ＩＭＤ ＢＡＮノードとインターフェースする方法（しかし、代表的な実施形態では、ノードの秘密デバイスキーＫｄｅｖを導出することなく）が、限られた原則で、本発明によるシステムのセキュリティプロトコルを迂回する方法でノードへの正当なアクセスを可能にすることができる。したがって、患者の予約を再スケジューリングする不便さが回避され、又は、真の緊急の状況では、患者への重要なケアが可能になる。 In a wireless telemetry system according to the present invention, as disclosed herein, a communication session between an in-vivo device and an extra-corporeal device can typically be initiated, executed, and closed completely wirelessly. Therefore, as discussed, it is important to prevent unauthorized and / or malicious parties from communicating with the embedded device or other nodes in the BAN. In practice, however, unauthorized extracorporeal devices (doctor programmer instruments, emergency response equipment, etc.) and their users (these users are not authorized in the sense that they do not have access to the embedded secret key, It will be appreciated that situations may arise where it is necessary to communicate with the implanted device (with the patient's explicit or implicit consent or instruction to access the BAN). Such a situation can occur, for example, in an emergency situation where the patient is undergoing a critical event or even a life-threatening physiological event, whether caused by the implant itself. For example, the patient is probably unconscious and may not have identifying material. There may also be situations where full authentication in the aspects of the present invention as described above is not feasible due to excessive inconvenience that authentication by the protocol is prohibited or not feasible. For example, a patient may have traveled large distances in an appointment to meet a doctor, but when they arrive, their smart card or other necessary to allow an extracorporeal node to communicate with the implant You may have forgotten or misplaced the material, or the patient may have forgotten their authentication password. In these situations, the “backdoor”, ie the method of interfacing with an IMD BAN node (but in the exemplary embodiment without deriving the node's secret device key K dev ), on a limited basis, A legitimate access to a node can be made possible in a way that bypasses the security protocol of the system according to the invention. Thus, the inconvenience of rescheduling patient appointments is avoided or, in a true emergency situation, important care for the patient is possible.

本発明の一実施形態では、たとえば或る距離にわたって、たとえば無線プロトコルとして、無線で動作する便利なバックドアメカニズムを提供することができる。一方、本発明の特定の実施形態では、バックドアは、無線ではなく、バックドアをオープンできる機器は、幅広く利用可能な場合がある（したがって、攻撃者が獲得することが容易である）。したがって、特定の実施形態におけるバックドアは、キーを共有するすべてのノードデバイスのセキュリティが、理由が何であれ、バックドアキーの相対的な機密性を危険にさらす動機を有する攻撃者によってノードデバイスの獲得時に取り返しのつかないほど危険にさらされるような方法では実施されない。したがって、無線バックドアが実施される本発明の特定の実施形態では、好ましくは、埋め込み物又はノード（たとえば、アリス１１５）全体の限られた量の機能しか、バックドアキーの通信時に動作可能ではない。たとえば、無線バックドアが利用可能である特定の実施態様では、無線バックドアを使用して、埋め込み物をそれぞれの静止（すなわち「スタンバイ」）モードにのみすることができる。より具体的には、たとえば、ペースメーカは、６０ｂｐｍモードに入ることができる一方、埋め込み可能な除細動器又はニューラルシミュレータ又は薬ポンプは、無線バックドアによって療法一時停止モードにすることができる。   In one embodiment of the present invention, a convenient backdoor mechanism can be provided that operates wirelessly over a distance, eg, as a wireless protocol. On the other hand, in certain embodiments of the present invention, the back door is not wireless, and devices that can open the back door may be widely available (and thus easy for an attacker to acquire). Thus, the backdoor in a particular embodiment is the acquisition of a node device by an attacker with the motivation to compromise the relative confidentiality of the backdoor key, regardless of the security of all node devices that share the key. It is not carried out in such a way that it is sometimes irretrievably endangered. Thus, in certain embodiments of the invention in which a wireless backdoor is implemented, preferably only a limited amount of functionality across the implant or node (eg, Alice 115) is operable during backdoor key communication. . For example, in certain embodiments where a wireless backdoor is available, the wireless backdoor can be used to place the implant only in its respective static (or “standby”) mode. More specifically, for example, a pacemaker can enter 60 bpm mode, while an implantable defibrillator or neural simulator or drug pump can be put into therapy suspend mode by a wireless backdoor.

図１６を参照して、本発明の特定の実施形態では、「物理的」バックドア１６１０、すなわち、無線通信チャネル１２０を使用しないアクセス方法、が提供される。これらの実施形態では、バックドアアクセスを求めるデバイス１１０と、アクセスされるノード１１５及び／又はその患者（埋め込められたデバイスの場合）との間の物理的な接触（又は近接近）によってのみ、認証なしのＢＡＮノード１１５へのアクセスが行われる。これは、特定のＢＡＮノード１１５では、ホール効果センサ又は磁気リードスイッチ等の近接場磁気センサの使用によって実施することができる。好ましくは、このセンサ１６１０は、通信チャネルそれ自体をもたらさず、（上記で説明したように）本発明の実施形態によって必要とされる認証要件なしで、モジュールを、機器が埋め込み物（複数可）又は他のノードと通信できるオープンモードにすることのみのために使用される。代替的に、バックドアは、磁気テレメトリー等の近い範囲のテレメトリーの手段を開始することができ、このテレメトリーでは、接近することによって、通信チャネルの使用が実際に可能になる。   Referring to FIG. 16, in a particular embodiment of the present invention, a “physical” backdoor 1610, ie, an access method that does not use the wireless communication channel 120 is provided. In these embodiments, authentication is only through physical contact (or close proximity) between the device 110 seeking backdoor access and the accessed node 115 and / or its patient (in the case of an implanted device). Access to the BAN node 115 with no access is made. This can be implemented at a particular BAN node 115 through the use of near-field magnetic sensors such as Hall effect sensors or magnetic reed switches. Preferably, this sensor 1610 does not provide a communication channel itself, and the module may be embedded by the device without the authentication requirements required by embodiments of the present invention (as described above). Or it is only used to put into an open mode that can communicate with other nodes. Alternatively, the backdoor can initiate a close range of telemetry means, such as magnetic telemetry, where the close proximity actually allows the use of the communication channel.

また、特定の実施形態では、緊急機器１１０が通信セッションをクローズすると、バックドア１６１０はクローズする。すなわち、オープン通信チャネルがクローズされ、デバイス１１５へさらに通信するには、たとえば本明細書で提供したような適用可能な認証情報が必要とされるか、又は代替的に、別のバックドア通信セッションの確立が必要とされる。このバックドアの使用の効果は、無線ルータ等の無線ネットワーク器具の埋め込まれたリセットボタンと比較することができる。リセットによって、リモートの第三者が無線ルータの態様を変更することが可能になるが、この状態は、デバイスにおける物理的な動作なしでは提供されない。デバイスへのこの物理的なアクセスは、デバイス又はノードに対する変更を管理する管理認証の代理として行われる。   Also, in certain embodiments, when the emergency device 110 closes the communication session, the back door 1610 closes. That is, the open communication channel is closed and further authentication to the device 115 requires applicable authentication information, eg, as provided herein, or alternatively, another backdoor communication session. Establishment is required. The effect of using this backdoor can be compared to an embedded reset button on a wireless network appliance such as a wireless router. A reset allows a remote third party to change the aspect of the wireless router, but this state is not provided without physical operation at the device. This physical access to the device is done on behalf of management authentication that manages changes to the device or node.

バックドアは、ＫＢＡＮをＢＡＮの他のデバイスへ配信する目的で、ＩＭＤからそのＫＢＡＮを抽出する好ましい手段としても使用することができる。また、バックドアは、ＩＭＤがエフェメラルＫＢＡＮ（ＫＢＡＮとして一時的に使用されるローカルに生成された乱数）を送信することを要求するのにも使用することができる。このエフェメラルＫＢＡＮは、そのテレメトリーセッションの継続時間の間にのみ有効である。バックドアアクセスの結果、ＫＢＡＮ又はエフェメラルＫＢＡＮの無線送信が可能になる実施態様では、エフェメラルＫＢＡＮを回復するのに必要なクレデンシャルに関して、ＩＭＤがＫＢＡＮを送信するために、追加されたクレデンシャルが必要とされる場合がある。このようなクレデンシャルは、たとえば１０秒といった延長された時間期間の間近接スイッチを起動することを含むことができる。ここで、エフェメラルＫＢＡＮの回復は、同じ近接スイッチの起動の時に３秒間だけ認可することができる。 The backdoor can also be used as a preferred means of extracting the K BAN from the IMD for the purpose of distributing the K BAN to other devices in the BAN . The backdoor can also be used to request that the IMD send an ephemeral K BAN (a locally generated random number used temporarily as K BAN ). This ephemeral K BAN is valid only for the duration of the telemetry session. In embodiments where K BAN or ephemeral K BAN can be transmitted wirelessly as a result of backdoor access, additional credentials are provided for the IMD to send K BAN with respect to the credentials required to recover the ephemeral K BAN. May be required. Such credentials can include activating the proximity switch for an extended time period, eg, 10 seconds. Here, the recovery of the ephemeral K BAN can be authorized only for 3 seconds when the same proximity switch is activated.

ＩＭＤ１１５に対するバックドア１６１０は、次のように具現化することができる。最初に、アリス１１５及びボブ１１０は、メッセージ１６１５及び１６２０を介してＩＤ（ＩＤＡ、ＩＤＢ）を交換することによって非セキュアチャネル１２０による通信セッションをオープンする。次に、ボブ１１０は、非セキュアチャネル１２０を介して、アリス１１５のバックドア回路部１６１０に電源を投入するようにアリス１１５に依頼する。このバックドア回路部１６１０は、通常ならば電源オフされ、たとえば磁石を接近させることのような、いずれの外部事象にも応答しない。たとえば、オフの時、バックドアは、「ロックされている」と言われる場合がある。バックドア回路部１６１０がオンになり、したがって、バックドア１６１０が「ロック解除」されると、ボブ１１０は、上述したように、磁気スイッチ又はホール効果センサ等の手段によってアリスのバックドアを物理的にオープンすることができる。好ましくは、バックドア１６１０が、所定のタイムアウト前に物理的にオープンされない場合、アリス１１５は、自身のバックドア回路部１６１０の電源を自動的に切り、バックドア１６１０を再ロックして、ホスト患者に接近することが攻撃者に可能である場合に攻撃を回避する。 The back door 1610 for the IMD 115 can be implemented as follows. Initially, Alice 115 and Bob 110 open a communication session over the non-secure channel 120 by exchanging IDs (ID A , ID B ) via messages 1615 and 1620. Next, Bob 110 requests Alice 115 to power on the backdoor circuit portion 1610 of Alice 115 via the non-secure channel 120. The backdoor circuit portion 1610 is normally powered off and does not respond to any external events, such as approaching a magnet. For example, when off, the backdoor may be said to be “locked”. When the backdoor circuit portion 1610 is turned on, and thus the backdoor 1610 is “unlocked”, Bob 110 physically moves Alice's backdoor by means such as a magnetic switch or Hall effect sensor as described above. Can be opened. Preferably, if the backdoor 1610 is not physically opened before a predetermined timeout, Alice 115 automatically powers off its backdoor circuitry 1610 and relocks the backdoor 1610 to allow the host patient If an attacker can get close to the attack, avoid the attack.

バックドア１６１０のオープンに続いて、アリス１１５は、自身のＲＦ送信電力を削減し（それによって、信号の有効な送信範囲を削減し）、次いで、メッセージ１６３０によってボブ１１０へＫＢＡＮ１６２５を送信する。アリス１１５は、この送信を行うと直ちに、自身のバックドア回路部１６１０の電源を切る。代表的な実施形態では、ＢＡＮキーの要求は、バックドアプロトコルの開始に暗に示されているので、ボブ１１０によるＢＡＮキーの要求は必要ではない。 Following the opening of backdoor 1610, Alice 115 reduces its RF transmit power (thus reducing the effective transmission range of the signal) and then sends K BAN 1625 to Bob 110 via message 1630. . As soon as Alice 115 makes this transmission, it turns off the power of its own backdoor circuit unit 1610. In the exemplary embodiment, a BAN key request by Bob 110 is not required because the BAN key request is implied at the beginning of the backdoor protocol.

図１７は、図１６の実施形態による緊急事態アクセスプロトコルの疑似プロトコル及びデータフローを示している。図１７に示すように、ブリッジデバイス１１０は、バックドアセッション要求１７１０によってＢＡＮキーを取得することができる。バックドアセッション要求１７１０に続いて、２つのノードは、２１５において、セキュアにされていないテレメトリーセッションを確立する。次に、ブリッジデバイス１１０は、バックドア回路部１６１０に電源が投入されることを要求することができる（１７１５）。これに応答して、ＩＭＤ１１５は、１７２０において、自身のバックドア回路部１６１０に電源を投入し、１７２５において、バックドア回路部１６１０に電源が投入されたことをブリッジデバイス１１０に確認する。次に、ブリッジデバイス１１０は、磁気スイッチ、ホール効果センサ、又は、バックドア１６１０を備える他の接近に基づくスイッチを接近させることによって、電源が投入されたバックドア１６１０を起動することができる。これは、１７３０によって示されている。   FIG. 17 illustrates the emergency access protocol pseudo-protocol and data flow according to the embodiment of FIG. As shown in FIG. 17, the bridge device 110 can obtain the BAN key by the backdoor session request 1710. Following the backdoor session request 1710, the two nodes establish an unsecured telemetry session at 215. Next, the bridge device 110 can request the backdoor circuit portion 1610 to be powered on (1715). In response to this, the IMD 115 turns on the power to the back door circuit unit 1610 at 1720 and confirms with the bridge device 110 that the power to the back door circuit unit 1610 is turned on at 1725. The bridge device 110 can then activate the powered back door 1610 by approaching a magnetic switch, Hall effect sensor, or other proximity based switch with the back door 1610. This is indicated by 1730.

バックドア１６１０がオープンすると（１７３０）、ＩＭＤ１１５は、１７３５に示すように、バックドアが接近ノード１１０によってオープンされたことに気付き、その後、１６２５において、非セキュアテレメトリーチャネル１２０によってＢＡＮキーを送信する。特定の実施形態では、ブリッジデバイス１１０は、１７３０において、ＢＡＮキーの受信の確認を送信することができるが、典型的な実施形態では、ＩＭＤ１１５は、ＢＡＮキーを送信するとバックドア１６１０の電源を直ちに切り、バックドアのオープンの別の要求１７１５が要求される。   When the back door 1610 opens (1730), the IMD 115 notices that the back door has been opened by the access node 110, as indicated at 1735, and then transmits a BAN key over the non-secure telemetry channel 120 at 1625. In certain embodiments, the bridge device 110 can send an acknowledgment of receipt of the BAN key at 1730, but in an exemplary embodiment, the IMD 115 immediately powers the back door 1610 upon sending the BAN key. Another request 1715 to turn off and open the back door is requested.

ＢＡＮ内の所与のデバイス又はノードが、上記セキュリティパラメータに従って十分にセキュアなテレメトリーセッションを開始することなく別のノードへデータを送信することが好都合であるさまざまな状況が存在する。たとえば、ＢＡＮは、セキュアな双方向リンクを確立できない送信のみのタイプのセンサである１つ又は複数のノードを含む場合がある。患者アクティベータ（patient activator）のような他のデバイスは、直ちに効果を与えることができるデータを送信することができる。したがって、本発明の実施形態は、データを含むウェイクアップパケットをセキュアにすること、及び、限られた量のセキュアなその後の通信を提供する。この文脈において、十分にセキュアなプロトコルは、一般的なセキュリティの確立と呼ばれ、あまり煩わしくないプロトコルは、ウェイクアップセキュリティ等と呼ばれる。   There are various situations where it is convenient for a given device or node in the BAN to send data to another node without initiating a sufficiently secure telemetry session according to the security parameters. For example, a BAN may include one or more nodes that are transmission-only types of sensors that cannot establish a secure bi-directional link. Other devices, such as patient activators, can send data that can be immediately effective. Accordingly, embodiments of the present invention provide for securing wake-up packets containing data and a limited amount of secure subsequent communication. In this context, a sufficiently secure protocol is called general security establishment, and a less troublesome protocol is called wake-up security or the like.

図１８は、ＢＡＮ内の認可されたデバイス（たとえば、アリス１１５）によって生成されたようなセキュアにされたウェイクアップパケット２０００をブロックの形態で示す図である。ウェイクアップパケット２０００は、特にアリス１１５のＩＤ、パケットを受信するノードのＩＤ等のような、図示しない他のデータも含むことができる。簡潔に言えば、ウェイクアップパケットは、４バイトの暗号化されていないデータ２０１０、３バイトのＭＡＣ２０２０、及び３バイトのＭＣＴＲ２０３０を含む。ＭＣＴＲは、特定のデバイスに関連付けられた３バイトのメッセージカウンタ値である。このメッセージカウンタ値は、ＢＡＮの各デバイス内に記憶され、その特定のデバイスが新しいセキュアなウェイクアップパケットを作成するごとにインクリメントされる。ＢＡＮ内の各デバイスは、ネットワーク内のあらゆるデバイスのオンメモリに常にＭＣＴＲの値を維持する。新しいデバイスがＢＡＮに追加された場合、ＭＣＴＲのすべての値がリセットされる。ＭＣＴＲ値は、ウェイクアップパケット２０００では暗号化されない。ＢＡＮの各デバイスは、ＭＣＴＲ値を維持することに加えて、目的とする受信者（複数可）として各デバイスを識別するのに使用される１バイト値であるレセプタビットマップも含む。   FIG. 18 is a block diagram illustrating a secured wake-up packet 2000 as generated by an authorized device (eg, Alice 115) in the BAN. Wake-up packet 2000 may also include other data not shown, such as the ID of Alice 115, the ID of the node receiving the packet, among others. Briefly, the wake-up packet includes 4 bytes of unencrypted data 2010, 3 bytes of MAC 2020, and 3 bytes of MCTR 2030. MCTR is a 3-byte message counter value associated with a particular device. This message counter value is stored in each device in the BAN and incremented each time that particular device creates a new secure wake-up packet. Each device in the BAN always maintains the value of MCTR in the on-memory of every device in the network. When a new device is added to the BAN, all values of MCTR are reset. The MCTR value is not encrypted in the wake-up packet 2000. In addition to maintaining the MCTR value, each device in the BAN also includes a receptor bitmap, which is a 1-byte value used to identify each device as the intended recipient (s).

ＭＣＴＲの値の追跡と共にＭＡＣ２０２０の生成によって、セキュリティがプロトコルに提供される。認可された受信デバイス（たとえば、ボブ１１０）は、受信時に、ＭＣＲ値２０３０を評価する。メッセージは、適切でない場合には無視される。適切である場合には、ＭＣＡは次に復号される。データ２０１０は、認証された場合には利用され、認証されない場合には、データは無視される。一実施形態では、ＡＣＫ／ＮＡＣＫメッセージ以外のそれ以上の交換は可能ではない。別の実施形態では、ウェイクアップパケットが認証されると、各ノードは、一般的なセキュリティの開始を必要とすることなく、限られた量のデータ（たとえば、１フレーム）の送信を可能にされる。   Security is provided to the protocol by generating the MAC 2020 along with tracking the value of the MCTR. An authorized receiving device (eg, Bob 110) evaluates the MCR value 2030 upon reception. Messages are ignored if not appropriate. If appropriate, the MCA is then decoded. The data 2010 is used when authenticated, and is ignored when not authenticated. In one embodiment, no further exchange other than ACK / NACK messages is possible. In another embodiment, once the wake-up packet is authenticated, each node is enabled to transmit a limited amount of data (eg, one frame) without requiring a general security initiation. The

図１９は、ＡＥＳブロック暗号２０９０を実行することによる（及び、先に図示して説明したような）ＭＡＣ２０２０の生成を示している。ＡＥＳブロック暗号２０９０の「ノンス」レジスタには、データセット２０４５がロードされる。データセット２０４５は、送信者のＩＤ（ＩＤｓｅｎｄｅｒ）を最上位６バイトとして含み、送信者の現在のＭＣＴＲ値（ＭＣＴＲｓｅｎｄｅｒ）を次の３バイトとして含む。次の４バイトは、送信されるデータであり、最後のバイトは、目的とする受信者（複数可）を示すレセプタビットマップである。ＢＡＮキー２１００も、ＡＥＳブロック暗号２０９０に入力される。ＡＥＳブロック暗号２０９０の結果の出力２１１０から、最下位３バイトのデータが、ＭＣＡ２０２０として指定される。 FIG. 19 illustrates the generation of a MAC 2020 by executing the AES block cipher 2090 (and as previously illustrated and described). The data set 2045 is loaded into the “nonce” register of the AES block cipher 2090. Data set 2045 includes the sender's ID (ID sender ) as the most significant 6 bytes and the sender's current MCTR value (MCTR sender ) as the next 3 bytes. The next 4 bytes are the data to be transmitted and the last byte is a receptor bitmap indicating the intended recipient (s). The BAN key 2100 is also input to the AES block cipher 2090. From the output 2110 of the result of the AES block cipher 2090, the least significant 3 bytes of data are designated as the MCA 2020.

図２０は、セキュアウェイクアップパケットを生成及び送信するためのプロセスのフローチャートである。この例では、「アリス」１１５は、「ボブ」１１０へデータパケットを通信することを意図している。アリス１１５は、４バイトのデータ（たとえば、アリスのセンサデータ、患者アクティベータのコマンド等）を生成又は獲得する（２２００）。アリス１１５は、ＭＣＴＲの現在の値をメモリから読み出し（２２１０）、図１９に関して説明したようにＡＥＳブロック暗号２０９０をポピュレートする（２２２０）。ＭＡＣが取得され、アリス１１５は、４バイトのデータ、ＭＡＣ、及びＭＣＴＲ値を含むウェイクアップパケット２０００を構成する（２２４０）。好ましくは、ＢＡＮ内の各デバイスは、許容可能な送信時間を指定している。アリス１１５は、適切な時間窓の期間中、構成されたメッセージを送信する（２２５０）。新しいセキュアウェイクアップメッセージが構成された時、アリス１１５は、ＭＣＴＲをインクリメントする（２２６０）。   FIG. 20 is a flowchart of a process for generating and transmitting a secure wakeup packet. In this example, “Alice” 115 is intended to communicate a data packet to “Bob” 110. Alice 115 generates or obtains 4 bytes of data (eg, Alice sensor data, patient activator command, etc.) (2200). Alice 115 reads the current value of the MCTR from memory (2210) and populates the AES block cipher 2090 as described with respect to FIG. 19 (2220). The MAC is acquired and Alice 115 constructs a wake-up packet 2000 including 2 bytes of data, MAC, and MCTR value (2240). Preferably, each device in the BAN specifies an acceptable transmission time. Alice 115 sends the configured message (2250) during the appropriate time window. When a new secure wakeup message is constructed, Alice 115 increments the MCTR (2260).

メッセージが適切に受信されたと仮定すると、アリス１１５は、受信者からＡＣＫメッセージを受信することができる（２２７０）。ＡＣＫメッセージが、予測されるが受信されない場合、又は、他のエラーが発生した場合、アリス１１５は、新しいＭＡＣを生成せず、且つ、ＭＣＴＲをインクリメントせずに同じメッセージを再送することができる（２２５０）。ＡＣＫがアリス１１５によって受信されると、ネイティブモードセッションが確立される（２２８０）。一実施形態では、これは、単に、アリスがデータの送信及び（適切な場合に）ＡＣＫメッセージの受信に成功したという点で、セッションが終了される（２２９０）ことを意味する。代替的な一構成では、ネイティブモードセッションを確立する（２２８０）ことによって、セッションに携わるＢＡＮの各デバイスは、たとえば１フレームといった限られた量のデータを送信することが可能になる。したがって、破線で示すように、アリス１１５は、さらなるフレームデータを送信する（２３００）。ネイティブセッションの各デバイスは、送信することが可能になり、したがって、アリス１１５は、ＢＡＮの別のデバイスからデータのフレームを受信することができる（２３１０）。ＡＣＫ／ＮＡＣＫメッセージが可能になり（２３２０）、セッションは、その後、終了される。   Assuming that the message was properly received, Alice 115 can receive an ACK message from the recipient (2270). If an ACK message is expected but not received, or if other errors occur, Alice 115 can retransmit the same message without generating a new MAC and without incrementing the MCTR ( 2250). If an ACK is received by Alice 115, a native mode session is established (2280). In one embodiment, this simply means that the session is terminated (2290) in that Alice has successfully transmitted the data and (if appropriate) received the ACK message. In an alternative configuration, establishing a native mode session (2280) allows each device in the BAN engaged in the session to transmit a limited amount of data, eg, one frame. Thus, as indicated by the dashed line, Alice 115 transmits additional frame data (2300). Each device in the native session is allowed to transmit, so Alice 115 can receive a frame of data from another device in the BAN (2310). An ACK / NACK message is enabled (2320) and the session is then terminated.

このように、ウェイクアップパケットがセキュアにされ、少量のデータが、一般的なセキュリティを確立せずに送信可能である。大量のデータを送信する必要がある場合、前述したように、一般的なセキュリティプロトコルが実施される。   In this way, the wake-up packet is secured and a small amount of data can be transmitted without establishing general security. When a large amount of data needs to be transmitted, a general security protocol is implemented as described above.

図２１は、たとえばボブ１１０といった受信ノードが、可能性のあるセキュアにされたウェイクアップメッセージの受信時に用いるプロセスのフローチャートである。ボブ１１０は、メッセージを受信し（２４００）、送信者を識別する（２４１０）。これは、たとえばアリス１１５への送信用に割り当てられたネットワークタイムスロットに基づいて行うこともできるし、他の識別手段に基づいて行うこともできる。いずれの場合も、ボブ１１０は、それが、その称するところ、メッセージを送信したアリス１１５であること、及び、ボブ１１０が目的とする受信者であることを識別する。ボブ１１０は、送信されたメッセージからＭＣＴＲ値を抽出し（２４２０）、ボブ１１０がアリス１１５についてメモリに記憶しているＭＣＴＲ値と比較する（２４３０）。ステップ２４４０において、受信されたＭＣＴＲ値が、ボブ１１０がアリスについて記憶している値よりも小さい場合、メッセージは無視される（２４５０）。ＭＣＴＲ値が、記憶されている値よりも大きい場合、ボブ１１０は、受信されたＭＣＴＲが正しいと一時的に仮定し（２４６０）、受信された値の利用に進む。同様に、受信されたＭＣＴＲ値が、記憶されている値に等しい場合、ボブ１１０は次のステップに進む。   FIG. 21 is a flowchart of a process used by a receiving node, eg, Bob 110, when receiving a possible secured wake-up message. Bob 110 receives the message (2400) and identifies the sender (2410). This can be done, for example, based on a network time slot assigned for transmission to Alice 115 or based on other identification means. In either case, Bob 110 identifies it as it is, Alice 115, who sent the message, and that Bob 110 is the intended recipient. Bob 110 extracts the MCTR value from the transmitted message (2420) and compares it with the MCTR value that Bob 110 stores in memory for Alice 115 (2430). In step 2440, if the received MCTR value is less than the value Bob 110 stores for Alice, the message is ignored (2450). If the MCTR value is greater than the stored value, Bob 110 temporarily assumes that the received MCTR is correct (2460) and proceeds to use the received value. Similarly, if the received MCTR value is equal to the stored value, Bob 110 proceeds to the next step.

いずれの場合も、受信されたＭＣＴＲを利用して、アリス１１５と同じ方法で、ＡＥＳブロック暗号２０９０によってＭＡＣが計算される。ボブ１１０によって計算されたＭＡＣ値は、ボブ１１０によって受信されたＭＡＣ値と比較される（２４８０）。これらのＭＡＣ値が一致しない場合、メッセージは無視される（２４９０）。これらのＭＡＣ値が一致する場合、ボブ１１０は、ネイティブモードに入り（２５００）、それに従ってデータを受理する（２５１０）。ボブ１１０は、アリス１１５に関連したＭＣＴＲ値を更新する（２５１５）。この結果、増分値が、アリス１１５によって送信されたＭＣＴＲ値の有効に加えられる。オプションとして、ボブ１１０は、ＡＣＫ／ＮＡＣＫメッセージをセキュアにして送信することができる（２５２０）。セッションは、その後、終了される（２５３０）。   In either case, the MAC is calculated by the AES block cipher 2090 in the same way as Alice 115 using the received MCTR. The MAC value calculated by Bob 110 is compared to the MAC value received by Bob 110 (2480). If these MAC values do not match, the message is ignored (2490). If these MAC values match, Bob 110 enters native mode (2500) and accepts data accordingly (2510). Bob 110 updates the MCTR value associated with Alice 115 (2515). As a result, the increment value is effectively added to the MCTR value transmitted by Alice 115. Optionally, Bob 110 can transmit the ACK / NACK message securely (2520). The session is then terminated (2530).

代替的な一実施形態では、ネイティブモードに入った（２５００）各ノードは、さらなるデータのフレームを送信することができる。したがって、ボブ１１０は、さらなる量のデータをアリス１１５へ送信することができ（２５４０）、同様に、アリス１１５は、さらなるデータのフレームを送信することができる（２５５０）。セッションキーは、セッション間の新しさを保証するために、ＭＡＣ出力の一部によって定められる。各ノードは、適切なＡＣＫ／ＮＡＣＫメッセージ２５２０を送信することが可能になり、セッションは、その後、終了される（２５３０）。ＡＥＳ＿ｏｕｔ２１１０、ＢＡＮキー２１００がＫｓｅｓの代わりに利用され、ノンスカウンタの最下位３バイトがＭＣＴＲ値で開始され、次に最上位２バイトがＭＣＴＲ値の最下位２バイトを利用し、最上位バイトが０で開始される点を除いて、パケット及びフレームは、一般的なセキュリティに関して、前述したようにセキュアにされる。   In an alternative embodiment, each node that entered native mode (2500) may transmit a frame of additional data. Thus, Bob 110 can transmit an additional amount of data to Alice 115 (2540), and similarly, Alice 115 can transmit a frame of additional data (2550). The session key is defined by a part of the MAC output to ensure freshness between sessions. Each node will be able to send the appropriate ACK / NACK message 2520 and the session is then terminated (2530). AES_out 2110, BAN key 2100 is used instead of Kses, the least significant 3 bytes of the nonce counter start with the MCTR value, then the most significant 2 bytes use the least significant 2 bytes of the MCTR value, and the most significant byte is 0 Except starting with, packets and frames are secured as described above for general security.

送信前に、オプションとして、ユーザデータの４バイトにデータプライバシー（暗号化）を適用することができる。暗号化及びその後の解読は、（ちょうどネイティブモード通信について行われるように）これらの４バイトのユーザバイトを４バイトのキーストリームとＸＯＲすることによって実現することができる。４バイトのキーストリームは、２１１０の未使用バイトから得ることもできるし、アリス及びボブの双方に知られている異なるノンス値を使用したブロック暗号の別の実行から得ることもできる。   Prior to transmission, data privacy (encryption) can optionally be applied to the 4 bytes of user data. Encryption and subsequent decryption can be achieved by XORing these 4 user bytes with a 4 byte key stream (just as is done for native mode communication). The 4-byte key stream can be obtained from 2110 unused bytes, or it can be obtained from another implementation of a block cipher using different nonce values known to both Alice and Bob.

本発明のさまざまな実施形態を説明してきたが、これらのさまざまな実施形態は、例示であって限定することを意図するものではない。開示された主題の複数の部分は、本発明の精神及び範囲内にあり、明示的に述べられていない実施形態において組み合わせることができる。   Although various embodiments of the invention have been described, these various embodiments are illustrative and not intended to be limiting. Multiple portions of the disclosed subject matter are within the spirit and scope of the invention and can be combined in embodiments that are not explicitly described.

Claims (82)

少なくとも第１のノード及び第２のノードを有する電気通信ネットワークにおいて、前記第１のノードから前記第２のノードへセキュアにされている(secured)テレメトリーウェイクアップパケット(wake-up packet)で使用可能データを送信する方法であって、該方法は、
前記第１のノード内で所定のプロトコルを使用してメッセージ認証コードを生成するステップと、
前記第１のノードによって作成された（authored）ウェイクアップ送信の数を示す現在のカウンタ値を前記第１のノードのメモリから取得するステップと、
前記第２のノードの識別情報(identification)を求める(determining)ステップと、
前記メッセージ認証コード、前記現在のカウンタ値、及び所定の量の使用可能データを含む、前記第２のノード用の送信可能なウェイクアップメッセージを構成(composing)するステップと、
前記ウェイクアップメッセージを送信するステップと、
を含む、方法。 Available in a telemetry wake-up packet that is secured from the first node to the second node in a telecommunication network having at least a first node and a second node A method for transmitting data, the method comprising:
Generating a message authentication code using a predetermined protocol in the first node;
Obtaining a current counter value indicative of the number of wake-up transmissions authorized by the first node from the memory of the first node;
Determining (identifying) the second node; and
Composing a transmittable wake-up message for the second node including the message authentication code, the current counter value, and a predetermined amount of usable data;
Sending the wake-up message;
Including a method. 前記メッセージ認証コードは、１２８ビットブロック暗号で生成される、請求項１に記載の方法。   The method of claim 1, wherein the message authentication code is generated with a 128-bit block cipher. 前記方法認証コードを生成することは、
前記第１のノードを示す識別子(identifier)を、前記ブロック暗号(block cipher)の入力レジスタに入力すること、
前記現在のカウンタ値を前記入力レジスタに入力すること、
前記使用可能データ(actionable data)を前記入力レジスタに入力すること、
前記第２のノードを示すレセプタ識別情報値(receptor identification value)を前記入力レジスタに入力すること、
前記ブロック暗号にネットワークキーを証明する(proving)こと、及び
少なくとも一部が前記方法認証コードを形成する、出力値を前記ブロック暗号から生成すること、
をさらに含む、請求項２に記載の方法。 Generating the method authentication code comprises:
Inputting an identifier indicating the first node into an input register of the block cipher;
Inputting the current counter value into the input register;
Inputting the actionable data into the input register;
Inputting a receptor identification value indicating the second node into the input register;
Providing a network key to the block cipher, and generating an output value from the block cipher, at least in part forming the method authentication code;
The method of claim 2 further comprising: 前記第２のノードから肯定応答(acknowledgement)メッセージを受信することをさらに含む、請求項１に記載の方法。   The method of claim 1, further comprising receiving an acknowledgment message from the second node. 使用可能データを含む前記ウェイクアップメッセージの送信の成功によって、ネイティブモードテレメトリーセッションが開始し、それによって、前記ネイティブモードにあるいずれのノードも、前記ウェイクアップパケットを受信するとＡＣＫ／ＮＡＣＫメッセージを送信することができる、請求項１に記載の方法。   Successful transmission of the wake-up message including usable data initiates a native mode telemetry session, whereby any node in the native mode transmits an ACK / NACK message when it receives the wake-up packet. The method of claim 1, wherein the method is capable. さらなるデータ交換を一切許可することなく(without permitting)、前記ネイティブモードセッションを終了することをさらに含む、請求項５に記載の方法。   6. The method of claim 5, further comprising terminating the native mode session without permitting any further data exchange. 前記ネイティブモードセッションに携わる(engaged in)各ノードが、所定の、及び、各ノードがＡＣＫ／ＮＡＣＫメッセージを送信できる、単一のデータパケットを送信することを可能にすること、及び
さらなるデータ交換を可能にすることなく、前記ネイティブモードセッションを終了すること、
をさらに含む、請求項５に記載の方法。 Allowing each node engaged in the native mode session to transmit a single data packet, and a predetermined, each node can send ACK / NACK messages, and further data exchange Ending the native mode session without enabling
The method of claim 5, further comprising: 前記第２のノードにおいて前記ウェイクメッセージを受信すること、
前記ウェイクアップメッセージの送信者を識別すること、
前記ウェイクアップメッセージから前記現在のカウンタ値を抽出すること、
前記現在のカウンタ値を、前記第２のノードのメモリ内に記憶されている第１のノードのカウンタ値と比較すること、
メッセージの有効性を評価する第１のメカニズムとして前記比較を利用すること、
前記ウェイクアップメッセージから前記メッセージ認証コードを抽出すること、
前記第２のノードによってアクセス可能な第１のノードのデータをブロック暗号で利用して、第１のノードのメッセージ認証コードを計算すること、
メッセージの有効性を評価する第２のメカニズムとして、前記第１のノードのメッセージ認証コードを、前記ウェイクアップメッセージから抽出された前記メッセージ認証コードと比較すること、及び
前記第１のメカニズム及び前記第２のメカニズムの双方がメッセージの有効性を示している場合に、前記ウェイクアップメッセージから前記使用可能データを受け入れること、
をさらに含む、請求項１に記載の方法。 Receiving the wake message at the second node;
Identifying the sender of the wake-up message;
Extracting the current counter value from the wake-up message;
Comparing the current counter value with a counter value of a first node stored in a memory of the second node;
Using the comparison as a first mechanism to evaluate the validity of a message;
Extracting the message authentication code from the wake-up message;
Using the data of the first node accessible by the second node in block cipher to calculate the message authentication code of the first node;
As a second mechanism for evaluating the validity of the message, comparing the message authentication code of the first node with the message authentication code extracted from the wake-up message, and the first mechanism and the first Accepting the available data from the wake-up message if both of the two mechanisms indicate the validity of the message;
The method of claim 1, further comprising: メッセージの有効性を評価する前記第１のメカニズムは、
前記現在のカウンタ値が、前記第２のノードの前記メモリに記憶されている前記第１のノードのカウンタ値よりも小さい場合には、前記ウェイクアップメッセージを無視すること、
前記第１のノードのカウンタ値が前記現在のカウンタ値に等しい場合には、前記第２のメカニズムに進む(advancing)と共に、前記第１のノードのカウンタ値を利用(utilizing)すること、及び
前記現在のカウンタ値が前記第１のノードのカウンタ値よりも大きい場合には、前記第２のメカニズムに進むと共に、前記現在のカウンタ値を利用すること、
をさらに含む、請求項８に記載の方法。 The first mechanism for evaluating the validity of a message is:
Ignoring the wake-up message if the current counter value is less than the counter value of the first node stored in the memory of the second node;
If the counter value of the first node is equal to the current counter value, proceeding to the second mechanism (advancing) and utilizing the counter value of the first node; and If the current counter value is greater than the counter value of the first node, proceed to the second mechanism and utilize the current counter value;
The method of claim 8, further comprising: 前記現在のカウンタ値が前記第１のノードのカウンタ値よりも大きく、且つ、前記第２のメカニズムがメッセージの有効性を示している場合には、前記第２のノードの前記メモリにおいて、前記第１のノードのカウンタ値を前記現在のカウンタ値に置き換えることをさらに含む、請求項９に記載の方法。   If the current counter value is greater than the counter value of the first node and the second mechanism indicates the validity of the message, the memory of the second node The method of claim 9, further comprising replacing a counter value of one node with the current counter value. 前記第２のメカニズムがメッセージの有効性を示している場合には、前記第２のデバイスの前記メモリにおいて、前記第１のノードのカウンタ値をインクリメントすることをさらに含む、請求項９に記載の方法。   10. The method of claim 9, further comprising incrementing a counter value of the first node in the memory of the second device if the second mechanism indicates message validity. Method. 前記第２のメカニズムがメッセージの有効性を示している場合には、ネイティブモードテレメトリーセッションに入ることをさらに含み、前記第２のノードは、ＡＣＫメッセージの送信を許可される、請求項９に記載の方法。   10. The method of claim 9, further comprising entering a native mode telemetry session if the second mechanism indicates message validity, wherein the second node is allowed to send an ACK message. the method of. さらなるデータ交換を許可することなく、前記テレメトリーセッションを終了することをさらに含む、請求項１２に記載の方法。   13. The method of claim 12, further comprising terminating the telemetry session without permitting further data exchange. 前記ネイティブテレメトリーモードにおいて各ノードからの単一のさらなるデータ送信の受信を可能にすること、前記第２のノードからの単一のデータ送信の送信を許可すること、及び、前記ネイティブテレメトリーモードの終了よりも前にＡＣＫ／ＮＡＣＫメッセージを送受信することをさらに含む、請求項１２に記載の方法。   Allowing reception of a single further data transmission from each node in the native telemetry mode, allowing transmission of a single data transmission from the second node, and exiting the native telemetry mode 13. The method of claim 12, further comprising sending and receiving an ACK / NACK message before. 少なくとも第１のノード及び第２のノードを有する電気通信ネットワークであって、前記第１のノードから前記第２のノードへセキュアにされているテレメトリーウェイクアップパケットで使用可能データを送信することを含み、
前記第１のノード内で所定のプロトコルを使用してメッセージ認証コードを生成する手段と、
前記第１のノードによって作成されたウェイクアップ送信の数を示す現在のカウンタ値を前記第１のノードのメモリから取得する手段と、
前記第２のノードの識別情報を求める手段と、
前記メッセージ認証コード、前記現在のカウンタ値、及び所定の量の使用可能データを含む、前記第２のノード用の送信可能なウェイクアップメッセージを構成する手段と、
前記ウェイクアップメッセージを送信する手段と、
を備える、ネットワーク。 A telecommunication network having at least a first node and a second node, comprising transmitting usable data in a telemetry wakeup packet secured from the first node to the second node ,
Means for generating a message authentication code using a predetermined protocol in the first node;
Means for obtaining a current counter value indicative of the number of wake-up transmissions created by the first node from the memory of the first node;
Means for obtaining identification information of the second node;
Means for constructing a transmittable wake-up message for the second node comprising the message authentication code, the current counter value, and a predetermined amount of usable data;
Means for transmitting the wake-up message;
With a network. 前記方法認証コードを生成することは、
前記第１のノードを示す識別子を、前記ブロック暗号の入力レジスタに入力する手段と、
前記現在のカウンタ値を前記入力レジスタに入力する手段と、
前記使用可能データを前記入力レジスタに入力する手段と、
前記第２のノードを示すレセプタ識別情報値を前記入力レジスタに入力する手段と、
前記ブロック暗号にネットワークキーを証明する手段と、
少なくとも一部が前記方法認証コードを形成する、出力値を前記ブロック暗号から生成する手段と、
をさらに備える、請求項１５に記載のネットワーク。 Generating the method authentication code comprises:
Means for inputting an identifier indicating the first node into an input register of the block cipher;
Means for inputting the current counter value into the input register;
Means for inputting the usable data into the input register;
Means for inputting a receptor identification information value indicating the second node to the input register;
Means for proving a network key to the block cipher;
Means for generating an output value from the block cipher, at least in part forming the method authentication code;
The network of claim 15, further comprising: 前記ウェイクアップメッセージの受信に成功するとネイティブモードテレメトリーセッションを開始する手段と、
前記ネイティブモードセッションに携わる各ノードが、所定の、及び、各ノードがＡＣＫ／ＮＡＣＫメッセージを送信できる、単一のデータパケットを送信することを許可する手段と、
さらなるデータ交換を一切許可することなく、前記ネイティブモードセッションを終了する手段と、
をさらに備える、請求項１６に記載のネットワーク。 Means for initiating a native mode telemetry session upon successful receipt of the wake-up message;
Means for allowing each node engaged in the native mode session to transmit a single data packet predetermined and each node can transmit an ACK / NACK message;
Means for terminating the native mode session without allowing any further data exchange;
The network of claim 16, further comprising: 前記第２のノードにおいて前記ウェイクメッセージを受信する手段と、
前記ウェイクアップメッセージの送信者を識別する手段と、
前記ウェイクアップメッセージから前記現在のカウンタ値を抽出する手段と、
前記現在のカウンタ値を、前記第２のノードのメモリ内に記憶されている第１のノードのカウンタ値と比較する手段と、
メッセージの有効性を評価する第１のメカニズムとして前記比較を利用する手段と、
前記ウェイクアップメッセージから前記メッセージ認証コードを抽出する手段と、
前記第２のノードによってアクセス可能な第１のノードのデータをブロック暗号で利用して、第１のノードのメッセージ認証コードを計算する手段と、
メッセージの有効性を評価する第２のメカニズムとして、前記第１のノードのメッセージ認証コードを、前記ウェイクアップメッセージから抽出された前記メッセージ認証コードと比較する手段と、
前記第１のメカニズム及び前記第２のメカニズムの双方がメッセージの有効性を示している場合に、前記ウェイクアップメッセージから前記使用可能データを受け入れる手段と、
をさらに備える、請求項１５に記載のネットワーク。 Means for receiving the wake message at the second node;
Means for identifying the sender of the wake-up message;
Means for extracting the current counter value from the wake-up message;
Means for comparing the current counter value with a counter value of a first node stored in a memory of the second node;
Means for utilizing the comparison as a first mechanism for evaluating the validity of a message;
Means for extracting the message authentication code from the wake-up message;
Means for calculating a message authentication code of the first node by using data of the first node accessible by the second node in a block cipher;
Means for comparing a message authentication code of the first node with the message authentication code extracted from the wake-up message as a second mechanism for evaluating the validity of the message;
Means for accepting the available data from the wake-up message when both the first mechanism and the second mechanism indicate message validity;
The network of claim 15, further comprising: メッセージの有効性を評価する前記第１のメカニズムは、
前記現在のカウンタ値が、前記第２のノードの前記メモリに記憶されている前記第１のノードのカウンタ値よりも小さい場合には、前記ウェイクアップメッセージを無視する手段と、
前記第１のノードのカウンタ値が前記現在のカウンタ値に等しい場合には、前記第２のメカニズムに進むと共に、前記第１のノードのカウンタ値を利用する手段と、
前記現在のカウンタ値が前記第１のノードのカウンタ値よりも大きい場合には、前記第２のメカニズムに進むと共に、前記現在のカウンタ値を利用する手段と、
をさらに備える、請求項１８に記載のネットワーク。 The first mechanism for evaluating the validity of a message is:
Means for ignoring the wake-up message if the current counter value is less than the counter value of the first node stored in the memory of the second node;
Means for proceeding to the second mechanism and utilizing the counter value of the first node if the counter value of the first node is equal to the current counter value;
Means for proceeding to the second mechanism and utilizing the current counter value if the current counter value is greater than the counter value of the first node;
The network of claim 18, further comprising: 前記現在のカウンタ値が前記第１のノードのカウンタ値よりも大きく、且つ、前記第２のメカニズムがメッセージの有効性を示している場合には、前記第２のノードの前記メモリにおいて、前記第１のノードのカウンタ値を前記現在のカウンタ値に置き換える手段をさらに含む、請求項１９に記載のネットワーク。   If the current counter value is greater than the counter value of the first node and the second mechanism indicates the validity of the message, the memory of the second node 20. The network according to claim 19, further comprising means for replacing a counter value of one node with the current counter value. 相互に通信する少なくとも第１のノード及び第２のノードを有する電気通信ネットワークにおいて、通信セッション中に前記少なくとも第１のノードと第２のノードとの間の少なくとも１つの通信をセキュアにする方法であって、
前記ネットワーク内において各ノードに一意の識別子を各ノードに割り当てるステップと、
前記ネットワーク内において各ノードに一意のデバイスキーを各ノードに割り当てるステップと、
ネットワークキーを前記ネットワークに割り当てるステップと、
前記少なくとも第１のノードと第２のノードとの間に通信セッションを確立するステップと、
前記ネットワークキーを少なくとも前記第２のノードに提供するステップと、
前記第２のノードの識別子を前記第１のノードに提供するステップと、
認可されていない発見を受けにくい方法で前記第２のノードのデバイスキーを前記第１のノードに提供するステップと、
前記第１のノードの識別子及び前記第２のノードの識別子を含む第１の通信を準備するステップと、
前記第２のノードのデバイスキーで前記第１の通信をセキュアにするステップと、
前記第１の通信を前記第２のノードへ送信するステップと、
前記第２のノードにおいて、前記第２のノードのデバイスキーを使用して前記第１の通信を解読するステップと、
前記第２のノードのデバイスキーが前記第１の通信をセキュアにするのに使用されたことの検証を条件として、前記第１のノードに前記ネットワークキーを提供するステップと、
前記ネットワークキーを使用して、前記少なくとも第１のノードと第２のノードとの間の第２の通信をセキュアにするステップと、
を含む、方法。 In a telecommunication network having at least a first node and a second node in communication with each other, in a method for securing at least one communication between said at least first node and a second node during a communication session There,
Assigning each node a unique identifier to each node in the network;
Assigning a unique device key to each node in the network;
Assigning a network key to the network;
Establishing a communication session between the at least first node and a second node;
Providing the network key to at least the second node;
Providing an identifier of the second node to the first node;
Providing a device key of the second node to the first node in a manner that is less susceptible to unauthorized discovery;
Preparing a first communication including an identifier of the first node and an identifier of the second node;
Securing the first communication with a device key of the second node;
Transmitting the first communication to the second node;
Decrypting the first communication at the second node using a device key of the second node;
Providing the network key to the first node, subject to verification that the device key of the second node was used to secure the first communication;
Securing a second communication between the at least first node and a second node using the network key;
Including a method. 認可されていない発見を受けにくい方法による前記第２のノードのデバイスキーの前記第１のノードへの提供は、物理トークンからの前記デバイスキーの入力によって行われる、請求項２１に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   The communication session of claim 21, wherein providing the first node device key of the second node to the first node in a manner that is less susceptible to unauthorized discovery is performed by inputting the device key from a physical token. A method of securing the at least one communication between the at least first node and a second node during. 前記認可されていない発見を受けにくい方法で前記第２のノードのデバイスキーを前記第１のノードに提供するステップは、
前記第２のノードのデバイスキーを物理トークン上に配置するステップと、
前記物理トークンから前記第１のノードへ前記第２のノードのデバイスキーを転送するステップと、
を含む、請求項２１に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。 Providing the first node with a device key of the second node in a manner that is less susceptible to unauthorized discovery;
Placing the device key of the second node on a physical token;
Transferring the device key of the second node from the physical token to the first node;
The method of securing the at least one communication between the at least first node and a second node during a communication session according to claim 21. 前記認可されていない発見を受けにくい方法で前記第２のノードのデバイスキーを前記第１のノードに提供するステップにおいて、前記第２のノードのデバイスキーは、前記物理トークン上に記憶され、前記物理トークンから前記第１のノードへ前記第２のノードのデバイスキーを転送するステップは、電子的に行われる、請求項２３に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   Providing the second node device key to the first node in a manner that is less susceptible to unauthorized discovery, wherein the second node device key is stored on the physical token, and 24. Transferring the second node device key from a physical token to the first node electronically is performed during the communication session of claim 23, wherein the at least first node and the second node are performed electronically. A method of securing the at least one communication with a computer. 前記物理トークンから前記第１のノードへ前記第２のノードのデバイスキーを電子的に転送する前記ステップは、前記第１のノードが前記デバイスキーを暗号化された形態で提供される方法で行われる、請求項２４に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   The step of electronically transferring the device key of the second node from the physical token to the first node is performed in such a way that the first node provides the device key in an encrypted form. 25. A method of securing the at least one communication between the at least first node and a second node during a communication session according to claim 24. 前記物理トークンは、少なくとも１つのプロセッサを含むキーフォブである、請求項２３に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   24. The method of securing the at least one communication between the at least first node and a second node during a communication session of claim 23, wherein the physical token is a key fob that includes at least one processor. . 前記第１の通信をセキュアにするステップは、前記キーフォブの前記少なくとも１つのプロセッサによって実行される、請求項２６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   27. Between the at least first and second nodes during a communication session of claim 26, wherein securing the first communication is performed by the at least one processor of the key fob. A method of securing the at least one communication. 前記物理トークンはスマートカードである、請求項２３に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   24. The method of securing the at least one communication between the at least first node and a second node during a communication session according to claim 23, wherein the physical token is a smart card. 前記第１の通信をセキュアにするステップは、前記スマートカードによって実行される、請求項２８に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   29. The at least one communication between the at least first node and a second node during a communication session according to claim 28, wherein securing the first communication is performed by the smart card. How to secure. 前記第２のノードのデバイスキーは、認証情報によって暗号化されて、前記スマートカード上に記憶される、請求項２９に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   30. The communication between the at least first node and the second node during a communication session according to claim 29, wherein the device key of the second node is encrypted with authentication information and stored on the smart card. A method of securing said at least one communication between. 前記認証情報は、パスワード文字の文字列を含む、請求項３０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   The method of securing the at least one communication between the at least first node and a second node during a communication session according to claim 30, wherein the authentication information includes a string of password characters. 前記認証情報は、バイオメトリックパラメータを含む、請求項３０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   31. The method of securing the at least one communication between the at least first node and a second node during a communication session according to claim 30, wherein the authentication information includes a biometric parameter. 前記ネットワークは、医療データサービスネットワークを含む、請求項２１に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   The method of securing the at least one communication between the at least first node and a second node during a communication session of claim 21, wherein the network comprises a medical data service network. 前記少なくとも第１のノード及び第２のノードのうちの少なくとも１つは、埋め込み可能医療デバイスを含む、請求項２１に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   The at least one of the at least first node and the second node comprises an implantable medical device between the at least first node and the second node during a communication session according to claim 21. A method of securing said at least one communication. 相互に通信する少なくとも第１のノード及び第２のノードを有する電気通信ネットワークにおいて、通信セッション中に前記少なくとも第１のノードと第２のノードとの間の少なくとも１つの通信をセキュアにする方法であって、
前記ネットワーク内において各ノードに一意の識別子を各ノードに割り当てるステップと、
前記ネットワーク内において各ノードに一意のデバイスキーを各ノードに割り当てるステップと、
ネットワークキーを前記ネットワークに割り当てるステップと、
前記少なくとも第１のノードと第２のノードとの間に通信セッションを確立するステップと、
前記ネットワークキーを少なくとも前記第１のノードに提供するステップと、
前記第２のノードの識別子を前記第１のノードに提供するステップと、
前記第２のノードのデバイスキーを前記第１のノードにセキュアに提供するステップと、
前記第１のノードの識別子、前記第２のノードの識別子、及び前記ネットワークキーを含む第１の通信を前記第２のノードから前記第１のノードへ送信するステップであって、該第１の通信は、前記第２のノードのデバイスキーでセキュアにされる、送信するステップと、
前記ネットワークキーを使用して、前記少なくとも第１のノード及び第２のノードの間の第２の通信をセキュアにするステップと、
を含む、方法。 In a telecommunication network having at least a first node and a second node in communication with each other, in a method for securing at least one communication between said at least first node and a second node during a communication session There,
Assigning each node a unique identifier to each node in the network;
Assigning a unique device key to each node in the network;
Assigning a network key to the network;
Establishing a communication session between the at least first node and a second node;
Providing the network key to at least the first node;
Providing an identifier of the second node to the first node;
Securely providing a device key of the second node to the first node;
Transmitting a first communication including the identifier of the first node, the identifier of the second node, and the network key from the second node to the first node, the first node comprising: Communication is secured with the device key of the second node, and transmitting
Securing a second communication between the at least first and second nodes using the network key;
Including a method. 前記ネットワークキーを使用して、前記少なくとも第１のノード及び第２のノードの間の前記第２の通信をセキュアにするステップは、
前記第１のノードにおいて、前記ネットワークキーと第１の任意の数との関数としてセッションキーを生成するステップと、
前記第２のノードにおいて、前記ネットワークキーと前記第１の任意の数との関数として前記セッションキーを独立に生成するステップと、
前記セッションキーを使用するステップであって、前記少なくとも第１のノード及び第２のノードの間の前記第２の通信をセキュアにする、使用するステップと、
を含む、請求項３５に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。 Securing the second communication between the at least first and second nodes using the network key, comprising:
Generating a session key as a function of the network key and a first arbitrary number at the first node;
Independently generating the session key as a function of the network key and the first arbitrary number at the second node;
Using the session key, securing the second communication between the at least first node and a second node;
36. A method of securing the at least one communication between the at least first node and a second node during a communication session according to claim 35. 前記第１の任意の数は疑似乱数である、請求項３６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   37. The method of securing the at least one communication between the at least first node and a second node during a communication session according to claim 36, wherein the first arbitrary number is a pseudo-random number. 前記第１の任意の数は、
前記第１のノードにおいて第２の任意の数を生成するステップと、
前記第２の任意の数を前記第２のノードに提供するステップと、
前記第２のノードにおいて第３の任意の数を生成するステップと、
前記第３の任意の数を前記第１のノードに提供するステップと、
前記第２の任意の数と前記第３の任意の数との双方の関数として前記第１の任意の数を生成するステップと、
を含む、任意の数を生成する方法によって生成される、請求項３６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。 The first arbitrary number is:
Generating a second arbitrary number at the first node;
Providing the second arbitrary number to the second node;
Generating a third arbitrary number at the second node;
Providing the third arbitrary number to the first node;
Generating the first arbitrary number as a function of both the second arbitrary number and the third arbitrary number;
37. A method of securing the at least one communication between the at least first node and a second node during a communication session according to claim 36, generated by a method of generating any number comprising: . 前記第２の任意の数及び前記第３の任意の数のうちの少なくとも一方は、疑似乱数である、請求項３８に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   The at least one of the at least first node and the second node during a communication session according to claim 38, wherein at least one of the second arbitrary number and the third arbitrary number is a pseudo-random number. A method of securing said at least one communication between. 前記セッションキーで前記少なくとも第１のノード及び第２のノードの間の前記第２の通信をセキュアにするステップは、暗号の出力と平文を含むメッセージとの間のビット単位のモジュロ２加算を実行するステップを含み、前記暗号の前記出力は、前記セッションキーと、前記通信セッション内において一意の第１のノンスとの双方の関数である、請求項３６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   Securing the second communication between the at least first and second nodes with the session key performs a bitwise modulo-2 addition between the cipher output and the message containing the plaintext 37. The step of claim 36, wherein the output of the cipher is a function of both the session key and a first nonce that is unique within the communication session. A method of securing the at least one communication between a second node and a second node. 前記第１のノンスは、前記通信セッション中に前記少なくとも第１のノードと第２のノードとの間で送信された個々の通信の数と、該個々の通信のサイズとの関数である、請求項４０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   The first nonce is a function of the number of individual communications transmitted between the at least first and second nodes during the communications session and the size of the individual communications. 41. A method of securing the at least one communication between the at least first node and a second node during a communication session according to clause 40. 前記個々の通信はパケットである、請求項４１に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   42. The method of securing the at least one communication between the at least first node and a second node during a communication session of claim 41, wherein the individual communication is a packet. 前記個々の通信の前記サイズは、ブロック単位で測定される、請求項４２に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   43. Secure the at least one communication between the at least first node and a second node during a communication session according to claim 42, wherein the size of the individual communication is measured in blocks. Method. 前記暗号はブロック暗号である、請求項４３に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   44. The method of securing the at least one communication between the at least first node and a second node during a communication session according to claim 43, wherein the cipher is a block cipher. アペンドされる個々の通信から導出される認証タグを各個々の通信にアペンドするステップをさらに含む、請求項４４に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   45. The method of claim 44, further comprising appending an authentication tag derived from the appended individual communication to each individual communication between the at least first node and the second node during a communication session. A method of securing the at least one communication. 前記認証タグは、前記セッションキーと、通信されている前記メッセージの前記平文との関数である、請求項４５に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   46. The communication between the at least first node and the second node during a communication session of claim 45, wherein the authentication tag is a function of the session key and the plaintext of the message being communicated. A method of securing the at least one communication. 前記認証タグは、第２のノンスの関数でもあり、該第２のノンスは、前記通信セッション中に前記ネットワークの前記少なくとも第１のノードと第２のノードとの間で送信された個々の通信の数の関数である、請求項４６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   The authentication tag is also a function of a second nonce, wherein the second nonce is an individual communication transmitted between the at least first and second nodes of the network during the communication session. 48. The method of securing the at least one communication between the at least first node and a second node during a communication session of claim 46, wherein the at least one communication is a function of a number of. 前記認証タグは、前記セッションキーと、通信されている前記メッセージの前記平文と、前記通信セッション中に前記ネットワークの前記少なくとも第１のノードと第２のノードとの間で送信された個々の通信の数との関数である、請求項４５に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   The authentication tag includes the session key, the plaintext of the message being communicated, and an individual communication transmitted between the at least first node and a second node of the network during the communication session. 46. The method of securing the at least one communication between the at least first node and a second node during a communication session of claim 45, wherein the at least one communication is a function of the number of nodes. 前記認証タグは、該認証タグがアペンドされる前記個々の通信に対して行われたハッシュ関数の結果である、請求項４５に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   46. The at least first node and second node during a communication session according to claim 45, wherein the authentication tag is a result of a hash function performed on the individual communication to which the authentication tag is appended. A method of securing the at least one communication with a computer. 相互に通信する少なくとも第１のノード及び第２のノードを有する電気通信ネットワークにおいて、通信セッション中に前記少なくとも第１のノードと第２のノードとの間の少なくとも１つの通信をセキュアにする方法であって、
前記ネットワーク内において各ノードに一意のデバイスキーを各ノードに割り当てるステップと、
ネットワークキーを前記ネットワークに割り当てるステップと、
前記少なくとも第１のノードと第２のノードとの間に通信セッションを確立するステップと、
前記第１のノードに任意の数を提供するステップと、
認可されていない発見を受けにくい方法で前記第２のノードのデバイスキーを前記第１のノードに提供するステップと、
前記第２のノードのデバイスキー及び前記任意の数で第１の通信をセキュアにするステップと、
前記第１の通信を前記第２のノードへ送信するステップと、
前記第２のノードにおいて、前記第２のノードのデバイスキー及び前記任意の数を使用して前記第１の通信を解読するステップと、
前記第１の通信が前記第２のノードのデバイスキー及び前記任意の数でセキュアにされたことが前記第２のノードにおいて検証されると、前記第１のノードに前記ネットワークキーを提供するステップと、
前記ネットワークキーを使用して、前記少なくとも第１のノード及び第２のノードの間の第２の通信をセキュアにするステップと、
を含む、方法。 In a telecommunication network having at least a first node and a second node in communication with each other, in a method for securing at least one communication between said at least first node and a second node during a communication session There,
Assigning a unique device key to each node in the network;
Assigning a network key to the network;
Establishing a communication session between the at least first node and a second node;
Providing an arbitrary number to the first node;
Providing a device key of the second node to the first node in a manner that is less susceptible to unauthorized discovery;
Securing the first communication with the device key of the second node and the arbitrary number;
Transmitting the first communication to the second node;
Decrypting the first communication at the second node using the device key of the second node and the arbitrary number;
Providing the first node with the network key when the second node verifies that the first communication has been secured with the device key of the second node and the arbitrary number. When,
Securing a second communication between the at least first and second nodes using the network key;
Including a method. 前記任意の数は疑似乱数である、請求項５０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   51. The method of securing the at least one communication between the at least first node and a second node during a communication session according to claim 50, wherein the arbitrary number is a pseudo-random number. 前記任意の数は、
参照キーとノンスとの双方の関数として第１の中間数を生成するステップと、
前記第１の中間値と初期化数と前記参照キーとの関数として前記任意の数を生成するステップと、
を含む、コンピュータによって実施される、任意の数を生成する、方法によって生成される、請求項５０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。 The arbitrary number is
Generating a first intermediate number as a function of both the reference key and the nonce;
Generating the arbitrary number as a function of the first intermediate value, an initialization number, and the reference key;
52. The at least one between the at least first node and the second node during a communication session of claim 50, wherein the at least one is generated by a computer-implemented method of generating any number To secure one communication. 前記参照キー及び前記初期化数のうちの少なくとも一方は任意である、請求項５２に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   53. Secure the at least one communication between the at least first node and a second node during a communication session of claim 52, wherein at least one of the reference key and the initialization number is arbitrary. How to make. 前記参照キー及び前記初期化数のうちの少なくとも一方は疑似乱数である、請求項５３に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   54. The at least one communication between the at least first node and a second node during a communication session of claim 53, wherein at least one of the reference key and the initialization number is a pseudo-random number. How to secure. 前記任意の数は疑似乱数である、請求項５４に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   55. The method of securing the at least one communication between the at least first node and a second node during a communication session according to claim 54, wherein the arbitrary number is a pseudo-random number. 前記任意の数は、前記参照キーと、前記第１の中間値及び前記初期化数のビット単位のモジュロ２加算の結果との関数である、請求項５５に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   56. The arbitrary number is a function of the reference key and a result of bitwise modulo-2 addition of the first intermediate value and the initialization number during the communication session of claim 55. A method of securing the at least one communication between a node and a second node. 前記任意の数は、前記第１の中間値及び前記初期化数のビット単位のモジュロ２加算の結果を前記参照キーで暗号化することによって生成される、請求項５６に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   57. During the communication session of claim 56, wherein the arbitrary number is generated by encrypting a bitwise modulo-2 addition result of the first intermediate value and the initialization number with the reference key. A method of securing the at least one communication between the at least first node and a second node. 前記第１の中間値及び前記初期化数のビット単位のモジュロ２加算の結果を前記参照キーで暗号化することは、ブロック暗号を使用して実施される、請求項５７に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   58. During a communication session according to claim 57, wherein encrypting the result of bitwise modulo-2 addition of the first intermediate value and the initialization number with the reference key is performed using a block cipher. A method of securing the at least one communication between the at least first node and a second node. 前記任意の数を生成する方法は、前記初期化数を前記任意の数で更新するステップをさらに含む、請求項５２に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。   53. The method of generating the arbitrary number further comprises updating the initialization number with the arbitrary number of the at least first and second nodes during the communication session of claim 52. A method of securing said at least one communication between. 前記任意の数は、
参照キーとノンスとの双方の関数として第１の中間数を生成するステップと、
前記第１の中間値と初期化数と前記参照キーとの関数として第２の中間数を生成するステップと、
前記第１の中間値と前記第２の中間値と前記参照キーとの関数として前記任意の数を生成するステップと、
を含む、コンピュータによって実施される、任意の数を生成する方法によって生成される、請求項５０に記載の通信セッション中に前記少なくとも第１のノードと第２のノードとの間の前記少なくとも１つの通信をセキュアにする方法。 The arbitrary number is
Generating a first intermediate number as a function of both the reference key and the nonce;
Generating a second intermediate number as a function of the first intermediate value, the initialization number and the reference key;
Generating the arbitrary number as a function of the first intermediate value, the second intermediate value, and the reference key;
51. The at least one between the at least first node and the second node during a communication session of claim 50, generated by a computer-implemented method of generating any number, comprising: A way to secure communications. 少なくとも２つのノードを備えるセキュア無線ネットワークであって、該少なくとも２つのノードのうちの少なくとも一方は、プログラマブルプロセッサ及びコンピュータ可読ストレージ素子を備え、前記コンピュータ可読ストレージ素子は、
参照キーとノンスとの双方の関数として第１の中間数を生成するステップと、
前記第１の中間値と初期化数と前記参照キーとの関数として第２の中間数を生成するステップと、
前記第１の中間値と前記第２の中間値と前記参照キーとの関数として任意の数を生成するステップと、
前記少なくとも２つのノードの間で送信される通信を前記任意の数でセキュアにするステップと、
を含む、任意の数を生成する方法を前記プログラマブルプロセッサに遂行させるための命令を含む、セキュア無線ネットワーク。 A secure wireless network comprising at least two nodes, at least one of the at least two nodes comprising a programmable processor and a computer readable storage element, the computer readable storage element comprising:
Generating a first intermediate number as a function of both the reference key and the nonce;
Generating a second intermediate number as a function of the first intermediate value, the initialization number and the reference key;
Generating an arbitrary number as a function of the first intermediate value, the second intermediate value and the reference key;
Securing the arbitrary number of communications transmitted between the at least two nodes;
A secure wireless network comprising instructions for causing the programmable processor to perform any number generating method. 物理トークンをさらに備え、前記物理トークン及び前記少なくとも２つのノードのうちの少なくとも１つは、前記プログラマブルプロセッサ及び前記コンピュータ可読ストレージ素子を備える、請求項６１に記載のセキュア無線ネットワーク。   64. The secure wireless network of claim 61, further comprising a physical token, wherein at least one of the physical token and the at least two nodes comprises the programmable processor and the computer readable storage element. 生物に埋め込むようになっている医療デバイスであって、
療法管理ユニットと、
電源と、
送信機と、
受信機と、
一意のデバイスキーと、
皮下動作可能な物理スイッチと、
該医療デバイスとネットワーク接続されたデバイスからの要求にのみ応答して、前記物理スイッチを起動可能にするようになっているスイッチ制御モジュールと、
を備える医療デバイス。 A medical device intended to be embedded in a living organism,
A therapy management unit;
Power supply,
A transmitter,
A receiver,
A unique device key,
A physical switch that can be operated subcutaneously;
A switch control module adapted to activate the physical switch only in response to a request from a device networked with the medical device;
A medical device comprising: 無線ネットワーク内の通信をセキュアにするようになっているネットワークキーと、
前記ネットワークキーを記憶するようになっている電子メモリと、
をさらに備え、
該医療デバイスは、前記物理スイッチの起動に応答して前記ネットワークキーを無線で送信するようになっている、請求項６３に記載の医療デバイス。 A network key designed to secure communications within the wireless network, and
An electronic memory adapted to store the network key;
Further comprising
64. The medical device of claim 63, wherein the medical device is adapted to wirelessly transmit the network key in response to activation of the physical switch. セッションキーと、
前記セッションキーを記憶するようになっている電子メモリと、
をさらに備え、
該医療デバイスは、前記物理スイッチの起動に応答して前記セッションキーを無線で送信するようになっている、請求項６３に記載の医療デバイス。 Session key and
An electronic memory adapted to store the session key;
Further comprising
64. The medical device of claim 63, wherein the medical device is configured to wirelessly transmit the session key in response to activation of the physical switch. 前記物理スイッチは、磁気リードセンサを備える、請求項６３に記載の医療デバイス。   64. The medical device of claim 63, wherein the physical switch comprises a magnetic reed sensor. 前記物理スイッチは、ホール効果センサを備える、請求項６３に記載の医療デバイス。   64. The medical device of claim 63, wherein the physical switch comprises a Hall effect sensor. 前記物理スイッチは、加速度計を備える、請求項６３に記載の医療デバイス。   64. The medical device of claim 63, wherein the physical switch comprises an accelerometer. 前記物理スイッチは、超音波センサを備える、請求項６３に記載の医療デバイス。   64. The medical device of claim 63, wherein the physical switch comprises an ultrasonic sensor. 前記物理スイッチは、光検出器を備える、請求項６３に記載の医療デバイス。   64. The medical device of claim 63, wherein the physical switch comprises a photodetector. 少なくとも２つのノードを備えるセキュア無線ネットワークであって、少なくとも１つのノードは、物理スイッチを有し、該物理スイッチは、該セキュア無線ネットワークに物理的に極めて接近しているときにのみ起動するようになっており、前記物理スイッチを有する前記少なくとも１つノードは、前記物理スイッチが起動すると、さらに、該セキュア無線ネットワーク上の少なくとも１つの他のノードへ秘密キーを送信するようにさらになっている、セキュア無線ネットワーク。   A secure wireless network comprising at least two nodes, wherein at least one node has a physical switch so that the physical switch is activated only when it is physically very close to the secure wireless network The at least one node having the physical switch is further configured to transmit a secret key to at least one other node on the secure wireless network when the physical switch is activated. Secure wireless network. 要求側デバイスをさらに備え、前記物理スイッチは、前記要求側デバイスが、該セキュア無線ネットワークのエリアに対して相対的に、前記物理スイッチを有する前記少なくとも１つのノードに物理的に極めて接近することによってのみ起動され、前記秘密キーは、ネットワークキー又はセッションキーである、請求項７１に記載のセキュア無線ネットワーク。   Further comprising a requesting device wherein the requesting device is physically close to the at least one node having the physical switch relative to an area of the secure wireless network. 72. The secure wireless network of claim 71, wherein the secure key is activated only and the secret key is a network key or a session key. 前記物理スイッチを有する前記少なくとも１つのノードは、前記セキュア無線ネットワークにおける別のノードから送信された要求があった時にのみ、前記物理スイッチを起動できる状態を該物理スイッチにおいて達成するようになっている、請求項７１に記載のセキュア無線ネットワーク。   The at least one node having the physical switch achieves a state in which the physical switch can be activated only when there is a request transmitted from another node in the secure wireless network. 72. A secure wireless network according to claim 71. テレメトリーセキュリティシステムによってセキュアにされ、第１の送信範囲を有する無線ネットワークにおいて、該無線ネットワークに対して自身を認証する認証情報を有しない非メンバーノードに、該無線ネットワークの少なくとも１つのメンバーノードへのアクセスを提供する方法であって、
前記少なくとも１つのメンバーノードに、要求側デバイスが物理的に接近することによって起動されるようになっている物理スイッチを提供するステップと、
要求側デバイスを、前記少なくとも１つのメンバーノードの前記物理スイッチに物理的に接近して配置することによって、該少なくとも１つのメンバーノードの該物理スイッチを起動するステップと、
前記物理スイッチを起動することに応答して、前記物理スイッチを有する前記少なくとも１つのメンバーノードの送信電力を削減するステップであって、前記第１の送信範囲よりも小さな第２の送信範囲を達成する、削減するステップと、
前記非メンバーノードを前記第２の送信範囲内に配置するステップと、
前記物理スイッチを有する前記少なくとも１つのメンバーノードから前記非メンバーノードへ認証情報を送信するステップと、
前記非メンバーノードによって、前記無線ネットワークの前記少なくとも１つのメンバーノードへ前記認証情報を提供することによって、前記無線ネットワークに対して前記非メンバーノードを認証するステップと、
を含む方法。 In a wireless network secured by a telemetry security system and having a first transmission range, to a non-member node that does not have authentication information authenticating itself to the wireless network, to at least one member node of the wireless network A method for providing access comprising:
Providing the at least one member node with a physical switch adapted to be activated upon physical proximity of a requesting device;
Activating the physical switch of the at least one member node by placing a requesting device in physical proximity to the physical switch of the at least one member node;
Responsive to activating the physical switch, reducing transmission power of the at least one member node having the physical switch, wherein a second transmission range smaller than the first transmission range is achieved. Step to reduce,
Placing the non-member node within the second transmission range;
Transmitting authentication information from the at least one member node having the physical switch to the non-member node;
Authenticating the non-member node to the wireless network by providing the authentication information to the at least one member node of the wireless network by the non-member node;
Including methods. 前記物理スイッチは、加速度計を備える、請求項１２に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。   The method of providing access to the at least one member node of the wireless network of claim 12, wherein the physical switch comprises an accelerometer. 前記物理スイッチは、超音波センサを備える、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。   The method for providing access to the at least one member node of the wireless network of claim 74, wherein the physical switch comprises an ultrasonic sensor. 前記物理スイッチは、磁気リードスイッチを備える、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。   75. The method for providing access to the at least one member node of the wireless network of claim 74, wherein the physical switch comprises a magnetic reed switch. 前記物理スイッチは、ホール効果センサを備える、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。   The method for providing access to the at least one member node of the wireless network of claim 74, wherein the physical switch comprises a Hall Effect sensor. 前記要求側デバイスは、磁石を備える、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。   75. The method for providing access to the at least one member node of the wireless network of claim 74, wherein the requesting device comprises a magnet. 前記磁石は、前記非メンバーノード内に統合されている、請求項７９に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。   80. The method for providing access to the at least one member node of the wireless network of claim 79, wherein the magnet is integrated within the non-member node. 前記無線ネットワークは、医療データサービスネットワークである、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。   75. The method for providing access to the at least one member node of the wireless network of claim 74, wherein the wireless network is a medical data service network. 前記要求側デバイスが物理的に接近することによって起動されるようになっている物理スイッチを有する前記少なくとも１つのメンバーノードは、埋め込み可能医療デバイスである、請求項７４に記載の前記無線ネットワークの前記少なくとも１つのメンバーノードへのアクセスを提供する方法。   75. The wireless network of claim 74, wherein the at least one member node having a physical switch adapted to be activated upon physical proximity of the requesting device is an implantable medical device. A method for providing access to at least one member node.
JP2009525689A 2006-08-18 2007-08-09 Secure telemetric link Pending JP2010507928A (en)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US83871806P 2006-08-18 2006-08-18
US82889807A 2007-07-26 2007-07-26
US11/828,867 US7930543B2 (en) 2006-08-18 2007-07-26 Secure telemetric link
US11/828,886 US7940933B2 (en) 2006-08-18 2007-07-26 Secure telemetric link
US11/828,940 US8102999B2 (en) 2006-08-18 2007-07-26 Secure telemetric link
PCT/US2007/075537 WO2008021920A2 (en) 2006-08-18 2007-08-09 Secure telemetric link

Publications (1)

Publication Number Publication Date
JP2010507928A true JP2010507928A (en) 2010-03-11

Family

ID=38760362

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009525689A Pending JP2010507928A (en) 2006-08-18 2007-08-09 Secure telemetric link

Country Status (3)

Country Link
EP (1) EP2060058A2 (en)
JP (1) JP2010507928A (en)
WO (1) WO2008021920A2 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011527464A (en) * 2008-06-18 2011-10-27 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ Personal security manager for ubiquitous patient monitoring
JP2012178680A (en) * 2011-02-25 2012-09-13 Olympus Corp Radio communication terminal
JP2015501593A (en) * 2011-10-28 2015-01-15 デバイオテック・ソシエテ・アノニム Secure communication between a medical device and its remote device
JP2015531184A (en) * 2012-07-09 2015-10-29 デバイオテック・ソシエテ・アノニム Protected communication between a medical device and its remote device
JP2016537887A (en) * 2013-11-13 2016-12-01 ジエマルト・エス・アー System and method for securing communication between a card reader device and a remote server
JP2018529405A (en) * 2015-08-11 2018-10-11 インスパイア・メディカル・システムズ・インコーポレイテッドＩｎｓｐｉｒｅ Ｍｅｄｉｃａｌ Ｓｙｓｔｅｍｓ， Ｉｎｃ． Platform for secure communication with medical devices
JP2020116376A (en) * 2018-12-11 2020-08-06 ソーリン シーアールエム エス ア エスＳｏｒｉｎ Ｃｒｍ Ｓ．Ａ．Ｓ． System and method for writing into memory of active implantable medical device by telemetry
CN113243910A (en) * 2015-01-21 2021-08-13 德克斯康公司 Communication of continuous glucose monitor with multiple display devices

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2306669A4 (en) 2008-07-18 2013-08-21 Panasonic Corp Transmission/reception device
US8652126B2 (en) 2009-11-24 2014-02-18 General Electric Company Method and computer program for authenticating a physiological sensor, a sensor system, a patient monitor, and a physiological sensor
US9157773B2 (en) * 2012-05-31 2015-10-13 General Electric Company Sensor validation method, patient monitor, physiological sensor, and computer program product for a patient monitor
EP3065658B1 (en) * 2013-11-05 2021-03-31 Pacira CryoTech, Inc. Secure cryosurgical treatment system
US10799704B2 (en) 2018-05-17 2020-10-13 At&T Intellectual Property I, L.P. Proximity-based security for implanted medical devices

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07297810A (en) * 1994-04-22 1995-11-10 Stanley Electric Co Ltd Data transmission equipment
JPH10210023A (en) * 1997-01-27 1998-08-07 Oki Electric Ind Co Ltd Authentication method, cipher key sharing method, and communication system
JPH1117769A (en) * 1997-06-20 1999-01-22 Nec Corp Confirmation type message communication system
JP2001217823A (en) * 1999-11-02 2001-08-10 Medtronic Inc Method and device for sesuring data transfer from medical device system
WO2005091546A2 (en) * 2004-03-15 2005-09-29 Cardiac Pacemakers, Inc. Cryptographic authentication for implantable medical device telemetry
WO2005091205A2 (en) * 2004-03-15 2005-09-29 Cardiac Pacemakers, Inc. Securely authenticating a data exchange session with an implantable medical device
WO2005099817A1 (en) * 2004-04-07 2005-10-27 Cardiac Pacemakers, Inc. Rf wake-up of implantable medical device

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07297810A (en) * 1994-04-22 1995-11-10 Stanley Electric Co Ltd Data transmission equipment
JPH10210023A (en) * 1997-01-27 1998-08-07 Oki Electric Ind Co Ltd Authentication method, cipher key sharing method, and communication system
JPH1117769A (en) * 1997-06-20 1999-01-22 Nec Corp Confirmation type message communication system
JP2001217823A (en) * 1999-11-02 2001-08-10 Medtronic Inc Method and device for sesuring data transfer from medical device system
WO2005091546A2 (en) * 2004-03-15 2005-09-29 Cardiac Pacemakers, Inc. Cryptographic authentication for implantable medical device telemetry
WO2005091205A2 (en) * 2004-03-15 2005-09-29 Cardiac Pacemakers, Inc. Securely authenticating a data exchange session with an implantable medical device
JP2007529274A (en) * 2004-03-15 2007-10-25 カーディアック・ペースメーカーズ・インコーポレーテッド Secure authentication of data exchange sessions using implantable medical devices
JP2007529959A (en) * 2004-03-15 2007-10-25 カーディアック・ペースメーカーズ・インコーポレーテッド Cryptographic authentication for telemetry of implantable medical devices
WO2005099817A1 (en) * 2004-04-07 2005-10-27 Cardiac Pacemakers, Inc. Rf wake-up of implantable medical device
JP2007532196A (en) * 2004-04-07 2007-11-15 カーディアック・ペースメーカーズ・インコーポレーテッド RF wakeup of implantable medical devices

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011527464A (en) * 2008-06-18 2011-10-27 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ Personal security manager for ubiquitous patient monitoring
JP2012178680A (en) * 2011-02-25 2012-09-13 Olympus Corp Radio communication terminal
US9178566B2 (en) 2011-02-25 2015-11-03 Olympus Corporation Wireless communication terminal
JP2015501593A (en) * 2011-10-28 2015-01-15 デバイオテック・ソシエテ・アノニム Secure communication between a medical device and its remote device
JP2015531184A (en) * 2012-07-09 2015-10-29 デバイオテック・ソシエテ・アノニム Protected communication between a medical device and its remote device
JP2016537887A (en) * 2013-11-13 2016-12-01 ジエマルト・エス・アー System and method for securing communication between a card reader device and a remote server
JP2022000156A (en) * 2015-01-21 2022-01-04 デックスコム・インコーポレーテッド Continuous glucose monitor communication with multiple display devices
US11797250B2 (en) 2015-01-21 2023-10-24 Dexcom, Inc. Continuous glucose monitor communication with multiple display devices
CN113243910A (en) * 2015-01-21 2021-08-13 德克斯康公司 Communication of continuous glucose monitor with multiple display devices
JP2018529405A (en) * 2015-08-11 2018-10-11 インスパイア・メディカル・システムズ・インコーポレイテッドＩｎｓｐｉｒｅ Ｍｅｄｉｃａｌ Ｓｙｓｔｅｍｓ， Ｉｎｃ． Platform for secure communication with medical devices
JP2021120006A (en) * 2015-08-11 2021-08-19 インスパイア・メディカル・システムズ・インコーポレイテッドInspire Medical Systems, Inc. Platform for secure communications with medical device
JP7161575B2 (en) 2015-08-11 2022-10-26 インスパイア・メディカル・システムズ・インコーポレイテッド A platform for medical devices and secure communications
US11344198B2 (en) 2018-12-11 2022-05-31 Sorin Crm Sas System and method for writing into the memory of an active medical device implantable by telemetry
JP7139304B2 (en) 2018-12-11 2022-09-20 ソーリン シーアールエム エス ア エス Systems and methods for writing to memory of active implantable medical devices via telemetry
JP2020116376A (en) * 2018-12-11 2020-08-06 ソーリン シーアールエム エス ア エスＳｏｒｉｎ Ｃｒｍ Ｓ．Ａ．Ｓ． System and method for writing into memory of active implantable medical device by telemetry

Also Published As

Publication number Publication date
WO2008021920A3 (en) 2008-05-02
EP2060058A2 (en) 2009-05-20
WO2008021920A2 (en) 2008-02-21

Similar Documents

Publication Publication Date Title
US8102999B2 (en) Secure telemetric link
US7930543B2 (en) Secure telemetric link
US8281408B2 (en) Secure telemetric link
JP2010507928A (en) Secure telemetric link
Wazid et al. A novel authentication and key agreement scheme for implantable medical devices deployment
CN102077545B (en) Personal security manager for ubiquitous patient monitoring
EP0539726B1 (en) Method to establish and enforce a network cryptographic security policy in a public key cryptosystem
Challa et al. Authentication protocols for implantable medical devices: Taxonomy, analysis and future directions
US8472630B2 (en) Method and system for establishing cryptographic communications between a remote device and a medical device
US7936878B2 (en) Secure wireless instrumentation network system
US9906502B2 (en) Pairwise temporal key creation for secure networks
Hosseini-Khayat A lightweight security protocol for ultra-low power ASIC implementation for wireless implantable medical devices
CN109391468A (en) A kind of authentication method and system
CN111080845B (en) Temporary unlocking method, system, door lock, administrator terminal and readable storage medium
JP2007529959A (en) Cryptographic authentication for telemetry of implantable medical devices
JP2022537733A (en) Authenticated key agreement
Park Security mechanism based on hospital authentication server for secure application of implantable medical devices
Siddiqi et al. Imdfence: Architecting a secure protocol for implantable medical devices
Shamshad et al. An efficient privacy-preserving authenticated key establishment protocol for health monitoring in industrial cyber–physical systems
Xu et al. A computationally efficient authentication and key agreement scheme for multi-server switching in WBAN
Chen et al. An internet-of-things-based sensing rural medical care system
Fu et al. POKs based low energy authentication scheme for implantable medical devices
Nagasundharamoorthi et al. Hash message authentication codes for securing data in wireless body area networks
Duttagupta et al. HAT: Secure and Practical Key Establishment for Implantable Medical Devices
CN115242435B (en) Multi-factor authentication system and method with verifiable attribute

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100615

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120904

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20121130

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130524

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130802

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20140217