JP7305871B2 - コントロールシステムにおける不正操作されたクライアントの識別 - Google Patents

Description

本発明は、請求項１の特徴を備えた、技術施設のコントロールシステムのクライアントサーバアーキテクチャにおけるインテグリティチェック方法に関する。さらに本発明は、請求項５の特徴を備えた、技術施設のコントロールシステムのためのクライアントサーバアーキテクチャに関する。これらに加えて本発明は、請求項６の特徴を備えた、技術施設のコントロールシステムのためのクライアントサーバアーキテクチャに関する。さらに本発明は、請求項８記載の技術施設のコントロールシステムに関する。

ウェブ指向のオペレータステーションクライアントは、オペレータステーションサーバのウェブサーバにログインし、それらのウェブサーバから、オペレーションおよびモニタリングに必要とされるコード（これは通例はＪａｖａ Ｓｃｒｉｐｔおよび／またはＨＴＭＬ５として提供されている）をロードし、このコードがクライアント側で実行される。これはたとえばオペレーティングビュー、メッセージシーケンス表示、トレンド表示、アラームバナー、ナビゲーション階層などである。

コードがオペレータステーションクライアントにロードされたときに、そこにおいてクライアントが（たとえばウィルス、侵入またはそれに類することにより）不正操作されてしまう可能性もあり、それによってたとえば、アラームがオペレータステーションクライアントにおいてもはや視覚化されなかったり、調整値およびプロセス値が誤った値を示したりといったようになる。したがってオペレータステーションクライアントにロードされたコードを、気づかれずに不正操作されないよう保護する必要がある。

たとえば、署名認証が失敗に終わったことにより不正操作を識別できるように、コードに相応に署名することができる。このような識別以上にプロセス技術施設の運転にとって極めて重要であるのは、万が一、不正操作が識別されたならばそれに対しただちに制裁措置を加え、かつ即座に復旧を軌道に乗せて、運転がそのことによってもできるかぎりそのまま変わらず、オペレーションおよびモニタリングを継続することができる、ということである。

現在のところ、オペレータステーションクライアントにロードされるコードは通例、不正操作から保護されておらず、または非常に初歩的なメカニズムによって保護されているにすぎない。しかも、万が一不正操作が行われたことに対し即座に制裁措置を加え、それに続いてシームレスに復旧させるための解決手段は存在していない。このため一方では、不正操作されたコードを気づかずにロードすることで損害が引き起こされるおそれがある。

他方、不正操作を識別したというケースでは、不正操作が識別されたならば不正操作されたコードを、ひいては不正操作されたクライアントを拒否する、というＩＴ分野で確立されている推奨を実施することによって、該当するプロセス技術施設の運転がかなり危うくなり、場合によっては施設が全面的に機能不全に陥ってしまう。

本発明が基礎とする課題は、技術施設のいっそう安全な運転を可能にし、万が一の不正操作から技術施設を効果的に保護する、技術施設のコントロールシステムのためのクライアントサーバアーキテクチャならびに方法を提供することである。

技術施設のコントロールシステムのクライアントサーバアーキテクチャにおいてインテグリティチェックする本発明による方法によれば、クライアントサーバアーキテクチャは、クライアントとして構成されて設けられている少なくとも１つの第１の装置と、サーバとして構成されて設けられている少なくとも１つの第２の装置とを含み、この方法は以下のステップを有する。すなわち、
ａ）クライアントがサーバにログイン(Anmeldung)し、クライアントにより実行すべきコードをサーバからダウンロードするステップと、
ｂ）サーバによって、秘密鍵を生成し、この秘密鍵をクライアントの公開鍵を用いて暗号化し、暗号化された秘密鍵に対する署名をサーバの公開鍵を用いて作成するステップと、
ｃ）事前に暗号化されて署名された秘密鍵をサーバからクライアントに伝送するステップと、
ｄ）暗号化されて署名された秘密鍵の署名をサーバの公開鍵を用いてチェックするステップと、
ｅ）事前にチェックされた署名が有効であるならば、クライアントによって、このクライアントのプライベート鍵を用いて、暗号化された秘密鍵を復号するステップと、
ｆ）クライアントによって、ハッシュ関数を用いてコードのハッシュ値を求めるステップと、
ｇ）クライアントによって、秘密鍵を用いてハッシュ値を暗号化し、暗号化されたこのハッシュ値をクライアントのプライベート鍵を用いて署名するステップと、
ｈ）暗号化されて署名されたハッシュ値をクライアントからサーバに伝送するステップと、
ｉ）サーバによって、暗号化されて署名されたハッシュ値の署名をクライアントの公開鍵を用いてチェックするステップと、
ｊ）事前にチェックされた署名が有効であるならば、サーバによって、暗号化されたハッシュ値を秘密鍵を用いて復号するステップと、
ｋ）サーバによって、このサーバに格納されておりクライアントには伝送されていないコードのコピーの付加的なハッシュ値を求めるステップと、
ｌ）ハッシュ値と付加的なハッシュ値とが一致しているならば、サーバは、クライアントと技術施設のコントロールシステムとの通信を許可するステップと
を有する。

技術施設を、たとえば化学施設、製薬施設、石油化学施設などプロセス産業に属する施設、または食料および嗜好品産業に属する施設とすることができる。これらと共に、たとえば自動車またはあらゆる種類の商品が製造される生産産業に属するいかなる施設、工場であっても含まれる。本発明による方法を実施するために適した技術施設を、エネルギー生成分野からのものとすることもできる。エネルギー生成のための風車、太陽エネルギー施設または発電所も技術施設の概念に含まれている。

これらの施設はそれぞれ、進行中のプロセスまたは生産を開ループ制御および閉ループ制御するために、コントロールシステムまたは少なくとも１つのコンピュータ支援型モジュールを有する。コントロールシステムとは本発明の文脈ではコンピュータ支援型技術システムのことであると解され、これは製造施設または生産施設といった技術システムの表示、操作および管理のための機能を含む。コントロールシステムはこのケースでは、測定値を求めるためのセンサならびに種々のアクチュエータを含む。これらに加えコントロールシステムは、アクチュエータもしくはセンサの制御に用いられるいわゆるプロセス近傍または製造近傍の構成要素を含む。さらにコントロールシステムは特に、技術施設の視覚化およびエンジニアリングのための手段を有する。コントロールシステムという用語を付加的に、もっと複雑な閉ループ制御のためのさらに別の計算ユニット、ならびにデータ記憶およびデータ処理のためのシステムであると捉えることもできる。

クライアントを、慣用のコンピュータ、スマートフォン、タブレット、サーバまたはこれらに類するものとすることができる。通例、クライアントは、クライアントのユーザに情報をグラフィックで提供する画像表示装置を有する。技術施設のコントロールシステムから情報を受け取る目的で、クライアントはサーバにログインし、実行用のコードを受け取る。

クライアントもサーバも非対称の鍵ペアを有し、それらのうちそれぞれ一方は公開鍵（ｐｕｂｌｉｃ ｋｅｙ）であり、他方はプライベート鍵（ｐｒｉｖａｔｅ ｋｅｙ）である。プライベート鍵をハードウェアにバインディングされたものとすることができる（たとえば基礎を成すハードウェアに組み込まれたいわゆるハードウェアセキュアエレメント、たとえばＴＰＭ（Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ）またはＨＳＭ（Ｈａｒｄｗａｒｅ Ｓｅｃｕｒｉｔｙ Ｍｏｄｕｌｅ））。セキュリティ要件が低いのであれば、プライベート鍵をたとえばＷｉｎｄｏｗｓ（登録商標）キーストアに格納しておくこともできる。

１つの鍵ペアにおける双方の鍵の間のバインディングを、信頼できる認証局（Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ，ＣＡ）から交付された証明書によって保証することができる。これをたとえば双方のパートナー（クライアントおよびサーバ）のＴＬＳ証明書、あるいは基礎を成すハードウェアにバインディングされたメーカ証明書（Ｍａｎｕｆａｃｔｕｒｅｒ Ｄｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅ）、あるいはＷｉｎｄｏｗｓアクティブディレクトリまたはＷｉｎｄｏｗｓワークグループにおいて発行されたＷｉｎｄｏｗｓ証明書とすることができる。同様に（個々の運用環境におけるトポロジーの境界条件が許すのであれば）、加入機器が自身の証明書をＬｅｔｓＥｎｃｒｙｐｔ ＣＡにおいて申請済みであるようにすることも可能である。

最も簡単な実施形態によれば、証明書を（場合によっては関連する鍵と共に）信頼できるプロバイダにおいて購入して取得し、加入機器の証明書ストアに格納することができ、その際には上述のようにプライベート鍵の保護について（その保管においても例外的に許可される伝送においても）特別な注意を払わなければならない。

いわゆるセキュアなハンドシェイク（たとえばＴＬＳハンドシェイク）の枠内で証明書を交換することによって、各加入機器の手元にそれぞれ他方の加入者のパブリック鍵があることが保証される。他方の加入機器のパブリック鍵によって、その加入者のために定められたメッセージを暗号化することができ、またはその加入者の署名を認証することができる。

ハッシュ関数とは一般に、比較的多い入力量をより少ない目標量（ハッシュ値）にマッピングする関数規則のことであると解される。

本発明による方法によれば、信頼できるクライアントは、ブラウザで実行されたコードが変更されていない、ということを（ウェブ）サーバに、ただしそのコードを平文でウェブサーバに伝送することなく、確信させることができるようになる。平文コードの代わりに、セキュアな手法で暗号化により形成された値が伝送される。しかも、上述の暗号化による値はクライアントにおいて実行されたコードに対して常に形成される、ということが保証される。

サーバからクライアントにロードされたコードが比較的長い期間にわたり変更されないままであったとしても、クライアントからサーバにチェックの目的で伝送される値が、潜在的な攻撃者にとってはランダムな値になる。したがって攻撃者は（たとえ攻撃者が複数の値を記録したとしても）それらからは役立つ推論を引き出すことはできず、そのような推論があったとしたならば、不正操作されたコードの実行にもかかわらず適正な値をサーバに伝達しようと試みる際に攻撃者を手助けすることができてしまう。かくして不正操作は識別されないままとなる。

不正操作をその場その場で識別するために用いられる上述のチェック方法を実行することによって、不正操作の試みをその場その場で識別することができ、したがって（ウィルスまたは攻撃者により）クライアントにおいて実行されたコードを気づかれずに不正操作することはできない、ということを保証することができる。これによって特に有利な手法で、コードのインテグリティおよび技術施設のコントロールシステムのインテグリティの維持にしっかりと貢献することができる。

ハッシュ値が一致していなければ、クライアントを技術施設のコントロールシステムとの通信から除外することができる。これによって、クライアントが誤ったもしくは不正操作されたコードを実行し、場合によっては技術施設のコントロールシステムに損害をもたらす、ということを回避することができる。

好ましくは、クライアントが、コントロールシステムとの通信から除外された後、新たにサーバにログインし、次いでこれまでに説明したインテグリティチェックの結果、ハッシュ値の一致が得られたならば、サーバはそのクライアントに対しコントロールシステムとの通信を再び許可する。このケースではクライアントの復旧という言葉が用いられる。新たにロードされたクライアントは、なぜそのクライアントがコントロールシステムの通信から除外されたのかの理由を、有利にはサーバから聞き知ることもできる。不正操作試行が識別された場合には即座に制裁措置を行い、それらのクライアントがもはや危険に晒されておらず、もはやセキュリティリスクを成していなければただちにクライアントを復旧させる、というこれまでに説明した完全に自動化された手順によって、技術システムの運転維持およびアベイラビリティ改善に貢献することができる。

本発明の有利な発展形態によれば、クライアントが、コントロールシステムとの通信から除外された後、新たにサーバにログインし、インテグリティチェックの結果、２回目もハッシュ値の一致が得られないケースであれば、サーバはそのクライアントをコントロールシステムとの通信からに除外し、そのクライアントを拒否すべき装置としてコントロールシステムに記録する。以降、そのクライアントはいわゆる「ブラックリスト」上に存在することになる。このブラックリストには、コントロールシステム内においてすべての加入機器、特にサーバ、がアクセスできるため、そのクライアントは他のサーバにももはやログインすることはできない。これは完全な制裁措置である。コントロールシステムの管理者だけがこのクライアントを、コントロールシステムとの通信をこのクライアントに対し再び許可する状態に移行させることができる。

さらに上述の課題は、技術施設のコントロールシステムのための以下のようなクライアントサーバアーキテクチャによって解決される。すなわちこのクライアントサーバアーキテクチャは、クライアントとして構成されて設けられている少なくとも１つの第１の装置と、サーバとして構成されて設けられている少なくとも１つの第２の装置とを含み、この第２の装置は、これまでに説明した方法を実施するように構成されている。

しかも上述の課題は、技術施設のコントロールシステムのための以下のようなクライアントサーバアーキテクチャによって解決される。すなわち、
このクライアントサーバアーキテクチャは、クライアントとして構成されて設けられている少なくとも１つの第１の装置と、クライアントに割り当てられたサーバとして構成されて設けられている少なくとも１つの第２の装置とを含み、
クライアントは、サーバとコンタクトをとり、サーバからコードを受信して実行するように構成されており、これによりサーバを介してクライアントからコントロールシステムへの通信が確立され、
サーバは、クライアントが実行するコードが、クライアントがサーバから受信したコードと一致しているか否かを識別するように構成されており、
サーバは、コードが一致していなければ、クライアントによるコードの実行を中断して、このクライアントをコントロールシステムとの通信から除外するように構成されている。この場合、好ましくは、サーバは以下のように構成されている。すなわち、クライアントが、コントロールシステムとの通信から除外された後、新たにサーバとコンタクトをとり、一致していないコードを実行したためにコントロールシステムとの通信から２回目も除外されたならば、そのクライアントを拒否すべき装置としてコントロールシステムに記録する。

上述の課題はさらに、これまでに説明したクライアントサーバアーキテクチャを備えた技術施設のコントロールシステムによって解決される。

本発明の上述の特性、特徴および利点、ならびにそれらを達成する手法は、図面を参照しながら詳しく説明する以下の実施例の記載と関連させることで、いっそうはっきりと明確に理解されるようになる。

本発明によるコントロールシステムの一部を示す図である。

図面には、プロセス技術施設として構成された技術施設における本発明によるコントロールシステム１の一部が示されている。コントロールシステム１は、オペレーションシステムの第１のサーバもしくは第１のオペレータステーションサーバ２と、第２のオペレータステーションサーバ３とを含む。これに加えコントロールシステム１は、オペレータステーションクライアント４を含む。第１のオペレータステーションサーバ２、第２のオペレータステーションサーバ３、およびオペレータステーションクライアント４は、端末バス５を介して互いに接続されており、さらにエンジニアリングシステムサーバまたはプロセスデータアーカイブなど、コントロールシステム１の図示されていないその他の構成要素と接続されている。

ユーザもしくはオペレータは、オペレータステーションクライアント４を用いることで端末バス５を介して、オペレーションおよびモニタリングという状況において、第１のオペレータステーションサーバ２および／または第２のオペレータステーションサーバ３にアクセスすることができる。端末バス５を、以下に限定されるものではないが、たとえば産業用イーサネットとして構成することができる。

オペレータステーションクライアント４は、「ローカルクライアントオブザーバ」と呼ばれる構成要素６を有する。第１のオペレータステーションサーバ２は、「クライアントオブザーバ」と呼ばれる構成要素７を有する。第２のオペレータステーションサーバ３も同様に、「クライアントオブザーバ」と呼ばれる構成要素８を有する。

構成要素「ローカルクライアントオブザーバ」６および「クライアントオブザーバ」７、８は、非対称の（パブリック鍵の）鍵のペアを使用することができ、この場合、“Ｘ”によって個々の非対称の秘密鍵（プライベート鍵）が表され、“Ｙ”によって個々の非対称の公開鍵（パブリック鍵）が表される。セキュリティ上の理由から、関連づけられたプライベート鍵は、理想的にはハードウェアにバインディングされているのが望ましく（つまり基礎を成すハードウェアに組み込まれたいわゆるハードウェアセキュアエレメント、たとえばＴＰＭまたはＨＳＭ）、あるいは択一的に（セキュリティ要件が低いのであれば）、たとえばＷｉｎｄｏｗｓキーストアまたは他のキーストアにセキュアに格納するのが望ましい。

クライアント４は、第１のオペレータステーションサーバ２にログインし、実行すべきコードをこのサーバからダウンロードする。第１のオペレータステーションサーバ２の構成要素「クライアントオブザーバ」７は、コードチェックプロセスを起動させ、その際に「クライアントオブザーバ」７は、（セキュリティ上の理由からできるかぎり疑似乱数値を用いて）秘密鍵を生成し、次いでこの秘密鍵を、構成要素「ローカルクライアントオブザーバ」６の公開鍵を用いて暗号化し、その結果（Ｅｎｃ）に自身の公開鍵で署名する（Ｓｉｇ）。これに続いて構成要素「クライアントオブザーバ」７は、この結果を構成要素「ローカルクライアントオブザーバ」６に伝達する。

この場合、使用される復号および署名の機能は、従来技術による機能である。“Ｅｎｃ”もしくは“Ｓｉｇ”に対応する機能を、以下では“Ｄｅｃ”もしくは“Ｖｅｒ”と称する。ここで留意されたいのは、暗号化機能もしくは署名機能の各々に対し常に１つの復号チェック機能もしくは署名チェック機能が存在する、ということである。対称の秘密鍵は、チェックプロセスごとに構成要素「クライアントオブザーバ」７によって新たに生成される。

構成要素「ローカルクライアントオブザーバ」６は、第１のオペレータステーションサーバ２の構成要素「クライアントオブザーバ」７から、値Ｅｎｃと関連づけられた署名Ｓｉｇとから成る値を受信する。最初に「ローカルクライアントオブザーバ」６は、オペレータステーションサーバ２の公開鍵を用いて、署名Ｓｉｇ（Ｅｎｃ）が有効であるか否かをチェックする：Ｖｅｒ（Ｓｉｇ（Ｅｎｃ）＝Ｔｒｕｅ？

署名が有効であるならば、「ローカルクライアントオブザーバ」６は、自身のプライベート鍵を用いて共通の対称の秘密鍵を復号する。次いで「ローカルクライアントオブザーバ」６は、第１のオペレータステーションサーバ２から受信したコードに対しハッシュ値を形成し（ｈａｓｈ＝ｈ（Ｃｏｄｅ））、その際にハッシュ関数ｈが用いられる。その後、クライアント４は、このハッシュ値を共通の対称の秘密鍵を用いて暗号化し、その結果に自身のプライベート鍵で署名する。これに続いてクライアント４は、暗号化および署名による結果全体を第１のオペレータステーションサーバ２の構成要素「クライアントオブザーバ」７に伝達する。伝送された値は、部外者もしくは攻撃者にはランダムに見える、という点に注意するのが重要である。既述のように、攻撃者は（たとえその攻撃者が複数の値を記録したとしても）、それらからは役に立つ推論を引き出すことはできず、そのような推論があったとしたならば、不正操作されたコードを実行したにもかかわらず適正な値を第１のオペレータステーションサーバ２に伝達しようと試みる際に攻撃者を手助けすることができてしまう。

第１のオペレータステーションサーバ２の構成要素「クライアントオブザーバ」７は、構成要素「ローカルクライアントオブザーバ」６から、実施すべきコードの暗号化された署名付きのハッシュ値を受信する。最初に構成要素「クライアントオブザーバ」７はクライアント４の公開鍵を用いて、署名が有効か否かをチェックする。署名が有効であるならば、構成要素「クライアントオブザーバ」６は、共通の対称の秘密鍵を用いてハッシュ値を復号する。次いで構成要素「クライアントオブザーバ」６は、この復号の結果が、第１のオペレータステーションサーバ２に格納されている適正なコードに対し形成された（つまりは適正な）ハッシュ値と一致しているか否かをチェックする。

一致しているのであれば、チェックプロセスは首尾よく終了し、つまりこのことは、第１のオペレータステーションサーバ２からクライアント４にロードされたコードが不正操作されていなかった、ということが確認されたということである。一致していなければ（不正操作が識別されたケースであれば）、以下で説明する制裁措置および復旧のための手順が実行される。

第１のオペレータステーションサーバ２が不正操作を識別したならば、第１のオペレータステーションサーバ２は目下実行されている命令（たとえば調整値変更、アラーム確認応答．．．）等をただちに中断する。さらに第１のオペレータステーションサーバ２は、目下のクライアントセッションを終了させ、つまり第１のオペレータステーションサーバ２はクライアント４を、少なくとも一時的にコントロールシステム１との通信から除外する。第１のオペレータステーションサーバ２は、相応のイベントもしくは相応のセキュリティメッセージを送出し、これによってコントロールシステム１の残りの部分に、クライアント４が不正操作されたかもしれないことを知らせる。さらに「ユーザプロフィルサービス」と称する構成要素９において、該当するクライアント４が「クライアントブラックリスト」１０に加えられる。これはさしあたりは注意書きであって、まだ実際にブロックするということではない。

第１のオペレータステーションサーバ２の「ミラーリング」と称する構成要素１１を介して、さらに別のオペレータステーションサーバ３が同じ識別状態に移行させられる。クライアント４がどのオペレータステーションサーバ２、３に再びログインしようが、コントロールシステム１には、クライアント４は不正操作ゆえにまずは「復旧」させられること、つまりいわば保護観察中であり、まだ全面的にはオペレーションおよびモニタリングから除外されてはいないことが既知である。

クライアント４とオペレータステーションサーバ２、３との新たな接続にあたり、不正操作されたかもしれないクライアント４内のコードが、個々のオペレータステーションサーバ２、３から新たにロードされる。このとき個々の構成要素「クライアントオブザーバ」７、８によるさらなるチェックにおいて、クライアント４が復旧させられているか否かが評価される。復旧させられているならば、このクライアント４をブラックリストから破棄することができる。復旧させられていないならば、クライアント４は相応にブロックされたままである。

第１もしくは第２のオペレータステーションサーバ２、３に組み込まれた構成要素「イベントマネージャ」１１、１２（既述の手順の枠内で捕捉されたすべてのイベントが基本的に保管される）によって、どのクライアント４が以前に場合によっては不正操作されていたのかには関係なく、それらがその間に復旧させられていたとしても、履歴解析もしくはフォレンジック解析（オーディットトレイル）を行うことができる。クライアント４のメッセージシーケンスディスプレイ１５は、第１もしくは第２のオペレータステーションサーバ２、３の個々のプロセスイメージ１３、１４を介して、イベントもしくはセキュリティメッセージにアクセスすることができる。

プロセスイメージに記録された実行環境のセキュリティメッセージを通して、プロセス技術施設のオペレーションおよびモニタリングのすべてのオペレータは、施設の運転にとって重要な情報を成す問題のあるクライアント４について把握している。コードチェックの常時監視、（不正操作が識別されたならば）対応するイベントの生成、ならびに（制裁措置の形態での）それに対する即座の応答の開始は、セキュリティ常時監視（英語では“Ｃｏｎｔｉｎｕｏｕｓ ｍｏｎｉｔｏｒｉｎｇ”）および通報されたイベントおよびアラームに対する即座の応答（英語では“Ｔｉｍｅｌｙ ｒｅｓｐｏｎｓｅ ｔｏ ｅｖｅｎｔｓ”）に関する主要な産業用セキュリティ標準であるＩＥＣ６２４４３の対応する要件への準拠に貢献する。

アベイラビリティおよびインテグリティはＩＥＣ６２４４３の最も重要な要件を成すことから、本発明は総じて（次第に義務化されつつある）証明および監査という状況で、ＩＥＣ６２４４３ならびにこれに基づく要件への準拠に貢献する。

好ましい実施例を通して本発明を細部にわたり詳しく例示し説明してきたけれども、本発明は開示された実施例に限定されるものではなく、当業者であれば本発明の保護範囲を逸脱することなく、そこから他の変形実施形態を導き出すことができる。

Claims (8)

1. 技術施設のコントロールシステム（１）のクライアントサーバアーキテクチャにおいて、クライアント（４）により実行すべきコードをサーバ（２、３）に格納されたコードとの一致についてインテグリティチェックする方法であって、
   前記クライアントサーバアーキテクチャは、クライアント（４）として構成され前記コントロールシステム（１）と通信するように構成されて設けられている少なくとも１つの第１の装置と、サーバ（２、３）として構成されて設けられている少なくとも１つの第２の装置とを含み、
   当該方法は、
   ａ）前記クライアント（４）が前記サーバ（２、３）にログインし、前記クライアント（４）により実行すべきコードを前記サーバからダウンロードするステップと、
   ｂ）前記サーバ（２、３）によって、秘密鍵を生成し、該秘密鍵を前記クライアント（４）の公開鍵を用いて暗号化し、暗号化された前記秘密鍵に対する署名を前記サーバの公開鍵を用いて作成するステップと、
   ｃ）事前に暗号化されて署名された前記秘密鍵を前記サーバ（２、３）から前記クライアント（４）に伝送するステップと、
   ｄ）前記クライアント（４）によって、暗号化されて署名された前記秘密鍵の前記署名を前記サーバ（２、３）の公開鍵を用いてチェックするステップと、
   ｅ）事前にチェックされた前記署名が有効であるならば、前記クライアント（４）によって、該クライアント（４）のプライベート鍵を用いて、暗号化された前記秘密鍵を復号するステップと、
   ｆ）前記クライアント（４）によって、ハッシュ関数を用いて前記コードのハッシュ値を求めるステップと、
   ｇ）前記クライアント（４）によって、前記秘密鍵を用いて前記ハッシュ値を暗号化し、暗号化された該ハッシュ値を前記クライアント（４）の前記プライベート鍵を用いて署名するステップと、
   ｈ）暗号化されて署名された前記ハッシュ値を前記クライアント（４）から前記サーバ（２、３）に伝送するステップと、
   ｉ）前記サーバ（２、３）によって、暗号化されて署名された前記ハッシュ値の前記署名を前記クライアント（４）の公開鍵を用いてチェックするステップと、
   ｊ）事前にチェックされた前記署名が有効であるならば、前記サーバ（２、３）によって、暗号化された前記ハッシュ値を前記秘密鍵を用いて復号するステップと、
   ｋ）前記サーバ（２、３）によって、該サーバ（２、３）に格納されており前記クライアント（４）には伝送されていない前記コードのコピーの付加的なハッシュ値を求めるステップと、
   ｌ）前記ハッシュ値と前記付加的なハッシュ値とが一致しているならば、前記サーバ（２、３）は、前記クライアント（４）と前記技術施設の前記コントロールシステムとの通信を許可するステップと、
   を含む、
   方法。
2. 前記ハッシュ値が一致していなければ、前記クライアント（４）は前記コントロールシステム（１）との通信から除外される、請求項１記載の方法。
3. 前記クライアント（４）が、前記コントロールシステム（１）との通信から除外された後、新たに前記サーバ（２、３）にログインし、請求項１記載のインテグリティチェックの結果、前記ハッシュ値の一致が得られたならば、前記サーバ（２、３）は前記クライアント（４）に対し、前記コントロールシステム（１）との通信を再び許可する、請求項２記載の方法。
4. 前記クライアント（４）が、前記コントロールシステム（１）との通信から除外された後、新たに前記サーバ（２、３）にログインし、請求項１記載のインテグリティチェックの結果、前記ハッシュ値の一致が得られなければ、前記サーバは、前記コントロールシステム（１）との通信から前記クライアント（４）を持続的に除外し、該クライアント（４）を拒否すべき装置として前記コントロールシステム（１）に記録する、請求項２記載の方法。
5. 技術施設のコントロールシステム（１）のためのクライアントサーバアーキテクチャであって、
   当該クライアントサーバアーキテクチャは、クライアント（４）として構成されて設けられている少なくとも１つの第１の装置と、サーバ（２、３）として構成されて設けられている少なくとも１つの第２の装置とを含み、該第２の装置は、請求項１から４までのいずれか１項記載の方法を実施するように構成されている、
   クライアントサーバアーキテクチャ。
6. 技術施設のコントロールシステム（１）のためのクライアントサーバアーキテクチャであって、
   当該クライアントサーバアーキテクチャは、クライアント（４）として構成されて設けられている少なくとも１つの第１の装置と、前記クライアント（４）に割り当てられたサーバ（２、３）として構成されて設けられている少なくとも１つの第２の装置とを含み、
   前記クライアント（４）は、前記サーバ（２、３）とコンタクトをとり、前記サーバ（２、３）からコードを受信して実行するように構成されており、これにより前記サーバ（２、３）を介して前記クライアント（４）から前記コントロールシステム（１）への通信が確立され、
   前記サーバ（２、３）は、前記クライアント（４）が実行するコードが、前記サーバ（２、３）に格納されており前記クライアント（４）に伝送されたコードと一致しているか否かを、請求項１から４までのいずれかに記載の方法を用いて識別するように構成されており、
   前記サーバ（２、３）は、前記コードが一致していなければ、該クライアント（４）との通信を中断することにより前記コントロールシステム（１）との通信から除外するように構成されている、
   クライアントサーバアーキテクチャ。
7. 前記クライアント（４）が、前記コントロールシステム（１）との通信から除外された後、新たに前記サーバ（２、３）とコンタクトをとり、一致していないコードを実行したために前記コントロールシステム（１）との通信から２回目も除外されたならば、前記サーバ（２、３）は、前記クライアント（４）を拒否すべき装置として前記コントロールシステム（１）に記録するように構成されている、請求項６記載のクライアントサーバアーキテクチャ。
8. 請求項５から７までのいずれか１項記載のクライアントサーバアーキテクチャを備えた技術施設のコントロールシステム（１）。

Images