JP7087015B2 - 情報処理装置、暗号化通信方法、およびプログラム - Google Patents

情報処理装置、暗号化通信方法、およびプログラム Download PDF

Info

Publication number
JP7087015B2
JP7087015B2 JP2020051239A JP2020051239A JP7087015B2 JP 7087015 B2 JP7087015 B2 JP 7087015B2 JP 2020051239 A JP2020051239 A JP 2020051239A JP 2020051239 A JP2020051239 A JP 2020051239A JP 7087015 B2 JP7087015 B2 JP 7087015B2
Authority
JP
Japan
Prior art keywords
algorithms
prohibited
encrypted communication
information processing
security
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.)
Active
Application number
JP2020051239A
Other languages
English (en)
Other versions
JP2020114002A (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.)
Canon Inc
Original Assignee
Canon 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
Application filed by Canon Inc filed Critical Canon Inc
Publication of JP2020114002A publication Critical patent/JP2020114002A/ja
Application granted granted Critical
Publication of JP7087015B2 publication Critical patent/JP7087015B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Facsimile Transmission Control (AREA)
  • Power Engineering (AREA)

Description

本発明は、情報処理装置、暗号化通信方法、およびプログラムに関し、特に、暗号化通信を行うために用いて好適なものである。
多くの情報機器は暗号化通信機能を備える。送信側の情報機器と受信側の情報機器との間で暗号化通信を行うことでネットワーク上での機密情報の漏洩を防ぐことができる。
通信の暗号化に利用されるアルゴリズムに係る技術として特許文献１に記載の技術がある。
特許文献１には、通信の暗号化に利用されるアルゴリズムを管理者がポリシーとして定めることにより、暗号化に利用されるアルゴリズムとして、ポリシーに従わないアルゴリズムを選択できないようにすることが開示されている。
特開２００９－９４６７６号公報
NIST,「Recommendation for Key Management: Part 1: General」、２００７年３月、インターネット＜URL:http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf＞
しかしながら、特許文献１に記載の技術では、ポリシーによる制限の対象は暗号化に利用されるアルゴリズムだけである。したがって、かかるポリシーは、暗号化通信を行う準備フェーズには影響を与えない。したがって、暗号化通信に先立って行われるハンドシェイクの際に、所定の安全性を満たすハッシュアルゴリズムを制御することができない。
そこで、本発明は、暗号化通信の先立って行われるハンドシェイクの際に、安全でないハッシュアルゴリズムが利用されることを抑制することを目的とする。
本発明の情報処理装置は、特定の暗号化通信プロトコルに従って外部装置と暗号化通信を行う情報処理装置であって、前記暗号化通信プロトコルで使用されるアルゴリズムのセットが、暗号強度に基づく安全性に関する基準とは異なる所定の条件を満たすか否かを判定することによって、当該アルゴリズムのセットが、利用が禁止されるアルゴリズムのセットであるか否かを、前記暗号化通信プロトコルで使用される複数のアルゴリズムのセットのそれぞれについて判定し、前記利用が禁止されないと判定したアルゴリズムのセットについて、暗号強度に基づく安全性に関する基準を満たすか否かを判定することを、前記複数のアルゴリズムを順番に選択して行う判定手段と、前記暗号化通信プロトコルで使用される複数のアルゴリズムのセットのうち、前記判定手段により前記所定の条件を満たさずに利用が禁止されると判定されたアルゴリズムのセットの利用と、前記判定手段により暗号強度に基づく安全性に関する基準を満たさないと判定されたアルゴリズムのセットの利用とを禁止する禁止手段と、前記複数のアルゴリズムのセットのうち、前記禁止手段により利用が禁止されないアルゴリズムのセットを利用して、前記暗号化通信に先立って前記外部装置との間で行われるハンドシェイクと前記暗号化通信とを行う通信手段と、を有し、前記禁止手段により利用が禁止されるアルゴリズムのセットは、前記ハンドシェイクの際に、前記情報処理装置の署名付きのメッセージを、前記外部装置に送信する必要があるアルゴリズムのセットであり、前記禁止手段により利用が禁止されるアルゴリズムのセットと、前記禁止手段により利用が禁止されないアルゴリズムのセットは、前記情報処理装置の認証のためのアルゴリズムを含み、前記暗号強度に基づく安全性に関する基準は、前記情報処理装置の証明書に対する署名に利用されるハッシュアルゴリズムの安全性に関する基準と、前記情報処理装置の証明書における公開鍵の安全性に関する基準と、の少なくとも何れか１つを含むことを特徴とする。
本発明によれば、暗号化通信の先立って行われるハンドシェイクの際に、安全でないハッシュアルゴリズムが利用されることを抑制することができる。
SSL/TLSによる通信の概要を説明する図である。 Handshakeによる通信を説明する図である。 サーバ証明書に含まれる情報を示す図である。 ネットワーク構成を示す図である。 複合機のハードウェアの構成を示す図である。 複合機のソフトウェアの構成を示す図である。 設定画面を示す図である。 複合機の処理の第１の例を説明するフローチャートである。 図８のステップＳ８０３の詳細を説明するフローチャートである。 図９のステップＳ９０２の詳細を説明するフローチャートである。 図９のステップＳ９０４の詳細を説明するフローチャートである。 利用が禁止されるCipher Suiteを示す図である。 複合機の処理の第２の例を説明するフローチャートである。 複合機の処理の第３の例を説明するフローチャートである。 図１４のステップＳ１４０４の詳細を説明するフローチャートである。
以下の各実施形態では、特定の暗号化通信プロトコルとして、SSL(Secure Socket Layer)またはTLS(Transport Layer Security)を用いる場合を例に挙げて説明する。そこで、まず、これらの暗号化通信プロトコルに基づく暗号化通信の概略の一例を説明する。尚、以下の説明では、SSLまたはTLSを必要に応じてSSL/TLSと表記する。
SSL/TLSで暗号化通信を行う場合、最初に、クライアントとサーバとの間で、ClientHelloメッセージ、ServerHelloメッセージの交換が行われる。これにより、クライアントとサーバとの間で通信プロトコルや暗号化通信に利用するCipher Suite（暗号スイート）の取り決めが行われる。
Cipher Suiteは、各種アルゴリズムのセットである。このアルゴリズムのセットには、以下の情報が含まれる。すなわち、「暗号化通信プロトコル名」、「鍵交換アルゴリズム」、「サーバ認証アルゴリズム」、「暗号化アルゴリズム」および「MAC（Message Authentication Code）の計算に利用するハッシュアルゴリズム」が含まれる。
すなわち、Cipher Suiteの構成は、"暗号化通信プロトコル名＿鍵交換アルゴリズム＿サーバ認証アルゴリズム＿with＿暗号化アルゴリズム＿MACの計算に利用するハッシュアルゴリズム"のようになる。
例えば、TLS＿DHE＿RSA＿WITH＿AES＿256＿CBC＿SHA（Cipher Suite）は、以下のことを表す。まず、暗号化通信プロトコルにTLSが利用される。鍵交換アルゴリズムにDHE（Diffie Hellman Ephemeral）が利用される。サーバ認証アルゴリズムにRSAが利用される。暗号化通信アルゴリズムにAES（２５６ビット、CBCモード）が利用される。MACの計算に利用するハッシュアルゴリズムにSHA1が利用される。
情報処理装置の間でSSL/TLSによる暗号化通信を行うには、クライアントとサーバの双方が同じCipher Suiteをサポートしている必要がある。このことから、暗号化通信を行う情報機器の多くは、複数のCipher Suiteをサポートすることで接続性を確保する。
一方で、計算機の性能の向上や、アルゴリズムの弱点の発見や、数学的進歩等の理由により、時間の経過とともに、これらの各種アルゴリズムの安全性は低下し、いずれは必要な安全性が確保できなくなる虞（危殆化の虞）がある。
アルゴリズムの安全性に関しては、例えばNIST（National Institute of Standards and Technology）が、非特許文献１において、米国連邦政府で利用する暗号アルゴリズムのガイドラインを定めている。NISTの策定は大きな影響力を持つ。したがって、NISTの定めたガイドラインは事実上、米国連邦政府だけでなく多くのベンダーやユーザも参照するガイドラインとなっている。
非特許文献１に記載されているように、各種アルゴリズム毎または鍵長（サイズ）毎に、それぞれ安全性を確保できるとされる期間が存在する。その期間を過ぎて当該アルゴリズムや当該鍵長（サイズ）の鍵を利用し続けることは、情報漏洩などのセキュリティ上のリスクに繋がる。そのため、例えば政府系機関など、特に機密性の高い情報を扱う環境においては、接続性よりも安全性が重視される。したがって、SSL/TLSによる暗号化通信の際は、非特許文献１において安全とされるアルゴリズムのみが利用されることを望む場合がある。
また、SSL/TLSは、図１に示すように、ハンドシェイク（Handshake）プロトコルと、レコード（Record）プロトコルとを有する。尚、以下の説明では、ハンドシェイクプロトコルを、必要に応じてHandshakeと略称する。また、レコードプロトコルを、必要に応じてRecordと略称する。
Handshakeでは、サーバ（Server）とクライアント（Client）とのそれぞれで、通信相手の認証と、鍵交換による共通鍵の共有とが行われる。Recordでは、Handshakeによりサーバとクライアントとで共有された共通鍵を利用した暗号化通信が行われる。
ここで、図２を用いて、Handshakeについてより詳細に説明する。
Handshakeでは、まず、クライアントがサーバに対し、接続要求としてClientHelloメッセージを送信する。ClientHelloメッセージには、クライアントが対応しているプロトコルバージョンやCipher Suiteの一覧の情報などが含まれる。また、Signature Algorithms extensionというオプション情報をClientHelloメッセージに含めることでクライアントが利用可能なハッシュアルゴリズム一覧をサーバに通知することも可能である。
サーバは、ClientHelloメッセージの情報から、利用するプロトコルバージョンやCipher Suiteを、例えば、サーバのCipher Suiteの優先順位に基づいて決定する。そしてサーバは、クライアントに対し、ServerHelloメッセージを送信する。ServerHelloメッセージには、サーバが決定したプロトコルバージョンやCipher Suiteの情報などが含まれる。
次に、サーバは、クライアントに対し、Certificateメッセージを送信する。Certificateメッセージには、X.509形式のサーバ証明書が含まれる。X.509形式のサーバ証明書には、例えば、図３に示す情報が含まれる。その後、前記のようにして決定したCipher Suiteによる鍵交換の方法によっては、サーバは、クライアントに対し、ServerKeyExchangeメッセージ（ハンドシェイクの際にサーバの署名つきのメッセージ）を送信する場合がある。このようなCipher Suiteでは、サーバとクライアントの双方が生成したパラメータから暗号鍵が生成される。
具体的には鍵交換アルゴリズムとしてDHE（Diffie Hellman Ephemeral）やECDHE（Elliptic Curve Diffie Hellman Ephemeral）などが利用される場合が該当する。一方、鍵交換アルゴリズムとして例えばRSAが利用される場合、ServerKeyExchangeメッセージは送信されることはない。
ServerKeyExchangeメッセージには、鍵交換のためのパラメータと、そのパラメータに対する署名などの情報が含まれる。このように、ServerKeyExchangeメッセージは、サーバの署名付きのメッセージである。
次に、サーバは、クライアントに対し、ServerHelloDoneを送信することで、サーバの一連の処理の終了をクライアントに通知する。
次に、クライアントは、ClientKeyExchangeメッセージをサーバに送信する。ClientKeyExchangeメッセージには、クライアントとサーバとで共有する暗号鍵の基となる情報が含まれる。
続けて、クライアントは、ChangeCipherSpecメッセージをサーバに送信する。これにより、クライアントは、以降の通信に使用されるデータは、取り決めたCipher Suiteによって暗号化されることをサーバに通知する。その後、クライアントは、Finishedメッセージをサーバに送信する。Finishedメッセージには、これまでの全てのメッセージが改ざんされていないことを確認するためのMAC値が含まれる。
その後、サーバは、クライアントに対し、ChangeCipherSpecメッセージ、Finishedメッセージをこの順で送信する。
以上でHandshakeが完了する。
特許文献１に記載の技術のように、ポリシーによる制限の対象を、暗号化に利用されるアルゴリズムだけにすると、ポリシーは、Recordにおける暗号化の安全性に関する強度にしか影響せず、Handshakeには影響しない。つまり、Cipher Suiteを構成する前述した４つのアルゴリズムのうち、制限の対象となるのは、暗号化アルゴリズムだけである。尚、前述した４つのアルゴリズムは、「サーバ認証アルゴリズム」、「鍵交換アルゴリズム」、「暗号化アルゴリズム」および「MACの計算に利用するハッシュアルゴリズム」である。
更に、仮に、Cipher Suiteを構成する個々のアルゴリズムを所定の安全性を満たすものに制限した場合であっても、以下の課題がある。すなわち、HandshakeにおけるServerKeyExchangeメッセージにおける署名に利用されるハッシュアルゴリズムを制御することはできない。その結果、弱いハッシュアルゴリズム（例えば、SHA1やMD5）が利用されてしまうという課題がある。ここで、本明細書では、非特許文献１で安全とされない、もしくは、非特許文献１に記載のないアルゴリズムを、弱い暗号（アルゴリズム）とする。尚、非特許文献１では、２０１０年以降は、SHA1を署名に利用することは安全ではないとされている。また、MD5については非特許文献１に記載がない。
そこで、以下では、SSL/TLSによる暗号化通信を行う場合を例に挙げて、ハンドシェイクの際に、弱いハッシュアルゴリズムが利用されないようにするための実施形態を、図面を用いて説明する。
（第１の実施形態）
まず、第１の実施形態を説明する。本実施形態では、SSL/TLSによる暗号化通信を行うサーバが、受信したClientHelloメッセージの情報によってCipher Suiteで利用する鍵交換の方法を制御する。これにより、SSL/TLSによる暗号化通信において弱いハッシュアルゴリズムの利用を防ぐことが可能となる。暗号化通信を行うサーバとなる情報処理装置は、例えば、複合機等の画像処理装置である。
図４は、暗号化通信を行うネットワーク構成の一例を示す図である。
複合機４０１とＰＣ（Personal Computer）４０２は、ネットワーク４０３を介して相互に通信可能に接続される。複合機４０１は、サーバとしてＰＣ４０２からのアクセス要求を受け付ける。アクセス要求は、例えば、Remote UI画面へのアクセス要求である。ＰＣ４０２からのアクセス要求があった場合、通信路を流れる情報（例えばログインのためのパスワードなどの認証情報）は、SSL/TLSによって暗号化される。
尚、本実施形態では、ネットワーク４０３を介して複合機４０１に通信可能に接続されるＰＣ４０２が１台の場合の例を示す。しかしながら、複合機４０１およびＰＣ４０２の数は、それぞれ１台に限定されない。
図５は、複合機４０１のハードウェアの構成の一例を示す図である。
ネットワークＩ／Ｆ（Interface）５０１は、ネットワーク４０３を介してＰＣ４０２などの外部装置と通信を行うためのものである。
ＵＩ（User Interface）操作部５０２は、複合機４０１に対するユーザによる操作の受け付けや、各種情報の表示を行う。尚、ユーザには、例えば、管理者とその他の一般ユーザが含まれる。
ＣＰＵ（Central Processing Unit）５０３は、プログラムコードを実行し、複合機４０１全体の制御を行う。
ＲＡＭ（Random Access Memory）５０４は、ＣＰＵ５０３が各種情報を処理するために一時的にデータを格納する。ＣＰＵ５０３が実行するプログラムコードや画像データなどがＲＡＭ５０４に格納される。
記憶装置５０５は、プログラムコード、画像データ、設定値、および暗号化鍵など、各種情報を保存する。
スキャナエンジン５０６は、用紙媒体に印刷された画像を光学的に読み取る。
印刷エンジン５０７は、電子写真技術やインクジェット技術などの既知の技術を用いて、画像データを用紙媒体に印刷する。
図６は、複合機４０１のソフトウェアの構成の一例を示す図である。特に断りのない限り、図６に示す各処理部は、記憶装置５０５に記憶された制御プログラムである。これらの制御プログラムは、ＣＰＵ５０３によって実行される。
画面制御部６０１は。ＵＩ操作部５０２を制御する。具体的に画面制御部６０１は、ＵＩ操作部５０２への各種情報の表示や、ＵＩ操作部５０２に対するユーザからの操作要求の受け付けなどを行う。
暗号化通信部６０２は、ネットワークＩ／Ｆ５０１を介して、外部装置と暗号化通信を行う。
暗号処理部６０３は、各種の暗号関連処理を行う。暗号関連処理には、データの暗号化・復号、ハッシュ値の生成、ＭＡＣの生成、および署名・検証などが含まれる。
設定値管理部６０４は、記憶装置５０５に格納されている設定値を変更する。この設定値の変更は、画面制御部６０１より管理者が、弱い暗号（弱いアルゴリズム）の利用を禁止するか否かの設定の変更を、設定画面を用いて行った際に実行される。図７は、設定画面７００の一例を示す図である。管理者が、ＵＩ操作部５０２に対して所定の操作を行うと、画面制御部６０１は、設定画面７００を表示する。
設定画面７００は、所定の暗号強度の暗号化通信を禁止するためのＧＵＩ（Graphic User Interface）である。管理者がＯＮボタン７０１を押下した上でＯＫボタン７０２を押下すると、設定値管理部６０４は、前記設定値を、弱い暗号（弱いアルゴリズム）の利用を禁止する設定を有効にすることを示す値にする。一方、管理者がＯＦＦボタン７０３を押下した上でＯＫボタン７０２を押下すると、設定値管理部６０４は、前記設定値を、弱い暗号の利用を禁止する設定を無効にすることを示す値にする。尚、ＯＫボタン７０２が押下されると、画面制御部６０１は、設定画面７００の表示を消す。また、管理者がキャンセルボタン７０４を押下した場合にも、画面制御部６０１は、設定画面７００の表示を消す。この場合、設定値管理部６０４は、設定画面７００に対する操作の内容に関わらず、前記設定値を変更しない。
暗号制御部６０６は、暗号化通信部６０２が暗号化通信を行う際に、設定値管理部６０４により管理される前記設定値を確認する。その結果、弱い暗号の利用を禁止する設定が有効である場合、暗号制御部６０６は、暗号化通信部６０２が利用してもよいCipher Suite（所定の条件を満たすアルゴリズムのセット）を制御する。
証明書管理部６０７は、暗号化通信部６０２がサーバ認証に利用するX.509形式のサーバ証明書（公開鍵証明書）や、対となる秘密鍵、プレインストールされているＣＡ証明書などを記憶装置５０５に格納し管理する。以下の説明では、サーバ証明書（公開鍵証明書）を必要に応じて証明書と略称する。
証明書処理部６０９は、証明書関連処理を行う。証明書管理処理には、証明書の解析・生成、必要な情報の抽出、および有効性検証などが含まれる。
以下、図８のフローチャートを用いて、複合機４０１の処理の一例を説明する。ここでは、弱い暗号の利用を禁止するポリシーが複合機４０１に適用されている際に、次の制御を行う場合を説明する。すなわち、SSL/TLSによる暗号化通信で利用するCipher Suiteを制限し、ServerKeyExchangeで弱いハッシュが利用されることを禁止するための制御を説明する。尚、図８に記載のフローチャートは、例えば、記憶装置５０５に格納された制御プログラムをＣＰＵ５０３が実行することによって実現される。
まず、ステップＳ８０１において、暗号化通信部６０２は、ネットワークＩ／Ｆ５０１を介して、ClientHelloメッセージを受信するまで待機する。以下の説明では、ClientHelloメッセージを、必要に応じてClientHelloと略称する。ClientHelloを受信すると、暗号化通信部６０２は、暗号化通信に利用してもよいCipher Suiteを暗号制御部６０６に問い合わせる。
次に、ステップＳ８０２において、暗号制御部６０６は、設定値管理部６０４により管理されている前記設定値を参照することで、弱い暗号の利用を禁止する設定が有効であるか否かを判定する。
この判定の結果、弱い暗号の利用を禁止する設定が有効でない場合には、ステップＳ８０３を省略して後述するステップＳ８０４に進む。この場合、暗号制御部６０６はCipherSuiteを制限しない。
一方、弱い暗号の利用を禁止する設定が有効である場合には、ステップＳ８０３に進む。ステップＳ８０３に進むと、暗号制御部６０６は、禁止処理を行う。本実施形態では、暗号制御部６０６は、SSL/TLSによる暗号化通信に利用可能なCipher Suiteを制限する処理を行う。そして、ステップＳ８０４に進む。
ステップＳ８０４に進むと、暗号制御部６０６は、利用が許可されているCipher Suiteを取得する。
次に、ステップＳ８０５において、暗号制御部６０６は、複合機４０１に設定されているCipher Suiteの優先度順において、優先度の最も高いCipher Suiteを選択する。
次に、ステップＳ８０６において、暗号化通信部６０２は、ステップＳ８０５で選択されたCipher Suiteを用いて、SSL/TLSによる暗号化通信を実行する。
次に、図８のステップＳ８０３の処理（Cipher Suiteを禁止する処理）の一例を、図９～図１１のフローチャートを用いて説明する。
図９のステップＳ９０１において、暗号制御部６０６は、ステップＳ８０１で受信したClientHelloにSignature Algorithms extensionが含まれているか否かを判定する。この判定の結果、Signature Algorithms extensionが含まれていない場合には、ステップＳ９０２に進む。尚、この場合には、ＰＣ４０２の証明書に対する署名に利用可能なハッシュアルゴリズムが提示されていない。
ステップＳ９０２に進むと、暗号制御部６０６は、判定処理を行う。本実施形態では、暗号制御部６０６は、暗号化通信部６０２がサポートしている個々のCipher Suiteが、ServerKeyExchangeメッセージが必要なCipher Suiteであるか否かを判定する。尚、以下の説明では、ServerKeyExchangeメッセージを必要に応じてServerKeyExchangeと略称する。
ServerKeyExchangeの必要性の有無は、例えば、Cipher Suiteに含まれる、サーバ認証アルゴリズムの名称および鍵交換アルゴリズムの名称を判別することで判定される。ステップＳ９０２の処理の具体例を、図１０を用いて説明する。
ステップＳ１００１において、暗号制御部６０６は、チェック対象のCipher Suiteに含まれるサーバ認証アルゴリズムがanon（anonymous）であるか否かを判定する。この判定の結果、サーバ認証アルゴリズムがanonである場合には、チェック対象のCipher Suiteは、ServerKeyExchangeが必要なCipher Suiteである。したがって、ステップＳ１００４に進み、暗号制御部６０６は、チェック対象のCipher Suiteの利用を禁止する。そして、図９のステップＳ９０２に進む。
一方、サーバ認証アルゴリズムがanonでない場合には、ステップＳ１００２に進む。ステップＳ１００２に進むと、暗号制御部６０６は、チェック対象のCipher Suiteに含まれる鍵交換アルゴリズムが、DHE（Diffie Hellman Ephemeral）であるか否かを判定する。この判定の結果、鍵交換アルゴリズムがDHEである場合には、チェック対象のCipher Suiteは、ServerKeyExchangeが必要なCipher Suiteである。したがって、ステップＳ１００４に進み、暗号制御部６０６は、チェック対象のCipher Suiteの利用を禁止する。そして、図９のステップＳ９０２に進む。
一方、鍵交換アルゴリズムがDHEでない場合は、ステップＳ１００３に進む。ステップＳ１００３に進むと、暗号制御部６０６は、チェック対象のCipher Suiteに含まれる鍵交換アルゴリズムがECDHE（Elliptic Curve Diffie Hellman Ephemeral）であるか否かを判定する。この判定の結果、鍵交換アルゴリズムがECDHEである場合には、チェック対象のCipher Suiteは、ServerKeyExchangeが必要なCipher Suiteである。したがって、ステップＳ１００４に進み、暗号制御部６０６は、チェック対象のCipher Suiteの利用を禁止する。そして、図９のステップＳ９０２に進む。
一方、ステップＳ１００３において、鍵交換アルゴリズムがECDHEでないと判定された場合には、図９のステップＳ９０２に進む。この場合、鍵交換アルゴリズムとサーバ認証アルゴリズムとが同じ（例えばRSA）であるので、ServerKeyExchangeは必要にならない。
図９の説明に戻り、以上のようにして、チェック対象のCipher Suiteが、ServerKeyExchangeが必要なCipher Suiteであるか否かがステップＳ９０２で判定されると、ステップＳ９０３に進む。
ステップＳ９０３に進むと、暗号制御部６０６は、ステップＳ９０２において、チェック対象のCipher Suiteの利用を禁止すると判定されたか否かを判定する。この判定の結果、チェック対象のCipher Suiteの利用を禁止すると判定された場合には、ステップＳ９０４を省略して、後述するステップＳ９０５に進む。
一方、チェック対象のCipher Suiteの利用を禁止すると判定されなかった場合、ステップＳ９０４に進む。すなわち、チェック対象のCipher SuiteがServerKeyExchangeを必要としないCipher Suiteである場合、ステップＳ９０４に進む。ステップＳ９０４に進むと、暗号制御部６０６は、判定処理を行う。本実施形態では、暗号制御部６０６は、チェック対象のCipher Suiteの安全性を更に判定する。
ステップＳ９０４の安全性の判定は、暗号化通信部６０２がサポートするCipher Suiteを構成する個々のアルゴリズムが弱いアルゴリズムであるか否かを確認することで行われる。ステップＳ９０４の処理の具体例を、図１１を用いて説明する。
ステップＳ１１０１において、暗号制御部６０６は、サーバ証明書の署名に利用されるハッシュアルゴリズムがSHA２（Secure Hash Algorithm２）であるか否かを判定する。
この判定の結果、ハッシュアルゴリズムがSHA２でない場合には、ステップＳ１１１２に進む。ステップＳ１１１２に進むと、暗号制御部６０６は、チェック対象のCipher Suiteの利用を禁止する。そして、図９のステップＳ９０５に進む。
一方、チェックした結果がSHA2である場合には、ステップＳ１１０２に進む。ステップＳ１１０２に進むと、暗号制御部６０６は、サーバ証明書の公開鍵アルゴリズムが、ECDSA（Elliptic Curve Digital Signature Algorithm）であるか否かを判定する。
この判定の結果、サーバ証明書の公開鍵アルゴリズムが、ECDSAである場合には、ステップＳ１１０３に進む。ステップＳ１１０３に進むと、暗号制御部６０６は、サーバ証明書における公開鍵の鍵長（サイズ）が２２４bit以上であるか否かを判定する。この判定の結果、公開鍵の鍵長（サイズ）が２２４bit以上でない場合には、ステップＳ１１１２に進む。ステップＳ１１１２に進むと、暗号制御部６０６は、チェック対象のCipher Suiteの利用を禁止する。そして、図９のステップＳ９０５に進む。
一方、公開鍵の鍵長（サイズ）が２２４bit以上である場合には、後述するステップＳ１１０５に進む。
ステップＳ１１０２において、サーバ証明書の公開鍵アルゴリズムが、ECDSAでない（つまりDSA（Digital Signature Algorithm）もしくはRSAである）と判定された場合には、ステップＳ１１０４に進む。ステップＳ１１０４に進むと、暗号制御部６０６は、サーバ証明書における公開鍵の鍵長（サイズ）が２０４８bit以上であるか否かを判定する。この判定の結果、サーバ証明書における公開鍵の鍵長（サイズ）が２０４８bit以上でない場合には、ステップＳ１１１２に進む。ステップＳ１１１２に進むと、暗号制御部６０６は、チェック対象のCipher Suiteの利用を禁止する。そして、図９のステップＳ９０５に進む。
一方、サーバ証明書における公開鍵の鍵長（サイズ）が２０４８bit以上である場合には、ステップＳ１１０５に進む。
尚、ステップＳ１１０１～Ｓ１１０４の判定は、例えば、証明書処理部６０９が、チェック対象のCipher Suiteのサーバ証明書のSignatureAlgorithmフィールドを確認した結果に基づいて行われる。
ステップＳ１１０５に進むと、暗号制御部６０６は、チェック対象のCipher Suiteに含まれる鍵交換アルゴリズムがECDH（Elliptic Curve Diffie Hellman）であるか否かを判定する。
この判定の結果、鍵交換アルゴリズムがECDHである場合には、ステップＳ１１０６に進む。ステップＳ１１０６に進むと、暗号制御部６０６は、鍵交換アルゴリズムで利用される公開鍵の鍵長（サイズ）が２２４bit以上であるか否かを判定する。この判定の結果、鍵交換アルゴリズムで利用される公開鍵の鍵長（サイズ）が２２４bit以上でない場合には、ステップＳ１１１２に進む。ステップＳ１１１２に進むと、暗号制御部６０６は、チェック対象のCipher Suiteの利用を禁止する。そして、図９のステップＳ９０５に進む。
一方、鍵交換アルゴリズムで利用される公開鍵の鍵長（サイズ）が２２４bit以上である場合には、後述するステップＳ１１０８に進む。
ステップＳ１１０５において、鍵交換アルゴリズムがECDHでない（つまりDHである）と判定された場合には、ステップＳ１１０７に進む。ステップＳ１１０７に進むと、暗号制御部６０６は、鍵交換アルゴリズムで利用される公開鍵の鍵長（サイズ）が２０４８bit以上であるか否かを判定する。この判定の結果、鍵交換アルゴリズムで利用される公開鍵の鍵長（サイズ）が２０４８bit以上でない場合には、ステップＳ１１１２に進む。ステップＳ１１１２に進むと、暗号制御部６０６は、チェック対象のCipher Suiteの利用を禁止する。そして、図９のステップＳ９０５に進む。
一方、鍵交換アルゴリズムで利用される公開鍵の鍵長（サイズ）が２０４８bit以上である場合には、ステップＳ１１０８に進む。
ステップＳ１１０８に進むと、暗号制御部６０６は、チェック対象のCipher Suiteに含まれる暗号化アルゴリズムがAES（Advanced Encryption Standard）であるか否かを判定する。この判定の結果、暗号化アルゴリズムがAESである場合には、後述するステップＳ１１１０に進む。
一方、暗号化アルゴリズムがAESでない場合には、ステップＳ１１０９に進む。ステップＳ１１０９に進むと、暗号制御部６０６は、チェック対象のCipher Suiteに含まれる暗号化アルゴリズムが３TDES（３key Triple Data Encryption Standard）であるか否かを判定する。この判定の結果、暗号化アルゴリズムが３TDESでない場合には、ステップＳ１１１２に進む。ステップＳ１１１２に進むと、暗号制御部６０６は、チェック対象のCipher Suiteの利用を禁止する。そして、図９のステップＳ９０５に進む。
一方、暗号化アルゴリズムが３TDESである場合には、ステップＳ１１１０に進む。ステップＳ１１１０に進むと、暗号制御部６０６は、チェック対象のCipher Suiteに含まれる、MACの計算に利用するハッシュアルゴリズムがSHA1であるか否かを判定する。この判定の結果、MACの計算に利用するハッシュアルゴリズムがSHA1である場合には、図９のステップＳ９０５に進む。
一方、MACの計算に利用するハッシュアルゴリズムがSHA1でない場合には、ステップＳ１１１１に進む。ステップＳ１１１１に進むと、暗号制御部６０６は、チェック対象のCipher Suiteに含まれるMACの計算に利用するハッシュアルゴリズムがSHA2であるか否かを判定する。この判定の結果、MACの計算に利用するハッシュアルゴリズムがSHA2である場合には、図９のステップＳ９０５に進む。
一方、MACの計算に利用するハッシュアルゴリズムがSHA2でない場合には、ステップＳ１１１２に進む。ステップＳ１１１２に進むと、暗号制御部６０６は、チェック対象のCipher Suiteの利用を禁止する。そして、図９のステップＳ９０５に進む。
図１２（ａ）は、利用が禁止されるCipher Suiteの第１の例を示す。図１２（ａ）において、「○」は、利用が可能なCipher Suiteであることを示す。一方、「×」は、利用が禁止されたCipher Suiteを示す。
以上のようにして、チェック対象のCipher Suiteについて、ステップＳ９０２もしくはステップＳ９０２、Ｓ９０４の両方による判定が終了すると、ステップＳ９０５に進む。ステップＳ９０５に進むと、暗号制御部６０６は、暗号化通信部６０２がサポートする全てのCipher Suiteに対して、ステップＳ９０１もしくはステップＳ９０１、９０３の両方による判定を完了したか否かを判定する。
この判定の結果、全てのCipher Suiteに対する判定が完了していない場合には、暗号化通信部６０２がサポートする全てのCipher Suiteに対して前述したステップＳ９０２～Ｓ９０４の処理を実行する。ステップＳ９０１～Ｓ９０３の処理を実行するCipher Suiteの順番としては、例えば、複合機４０１に設定されているCipher Suiteの優先度順が挙げられる。しかしながら、かかる順番は、これに限定されるものではない。そして、図８のステップＳ８０４に進む。
前述した図９のステップＳ９０１において、ステップＳ８０１で受信したClientHelloにSignature Algorithms extensionが含まれている場合には、ステップＳ９０６に進む。尚、この場合には、ＰＣ４０２の証明書に対する署名に利用可能なハッシュアルゴリズムが提示されている。ステップＳ９０６に進むと、暗号制御部６０６は、Signature Algorithms extensionにSHA2が含まれているか否かを判定する。
この判定の結果、SHA2が含まれていない場合は、ステップＳ９０１でSignature Algorithms extensionが含まれていないと判定された場合と同様に、前述したステップＳ９０２に進む。
一方、SHA2が含まれている場合は、ステップＳ９０７に進み、暗号制御部６０６は、判定処理を行う。ステップＳ９０７の処理は、前述したステップＳ９０４の処理と同じであるため、その詳細な説明を省略する。そして、ステップＳ９０８に進む。
図１２（ｂ）は、利用が禁止されるCipher Suiteの第２の例を示す。図１２（ｂ）において、「○」は、利用が可能なCipher Suiteであることを示す。一方、「×」は、利用が禁止されたCipher Suiteを示す。
ステップＳ９０８に進むと、暗号制御部６０６は、暗号化通信部６０２がサポートする全てのCipher Suiteに対して、ステップＳ９０７による判定を完了したか否かを判定する。
この判定の結果、全てのCipher Suiteに対する判定が完了していない場合には、暗号化通信部６０２がサポートする全てのCipher Suiteに対して前述したステップＳ９０７の処理を実行する。ステップＳ９０７の処理を実行するCipher Suiteの順番としては、例えば、複合機４０１に設定されているCipher Suiteの優先度順が挙げられる。しかしながら、かかる順番は、これに限定されるものではない。
図１０～図１２に示すように、本実施形態では、サーバ（本実施形態では複合機４０１）の公開鍵を用いて暗号鍵を交換するCipher Suiteについては、利用が許可される。
以上のように本実施形態では、弱い暗号の利用を禁止する設定が複合機４０１に適用されている場合に、受信したClientHelloの情報によってCipherSuiteで利用する鍵交換方法を制御する。より、具体的には、ClientHelloにSHA2を含むSignature Algorithms extensionがある場合は、ServerKeyExchangeが必要となる鍵交換を許可する。一方、ClientHelloにSHA2を含むSignature Algorithms extensionがない場合は、ServerKeyExchangeが必要となる鍵交換を利用しないようにする。
これにより、SSL/TLSによるServerKeyExchangeにおいても、MD5やSHA1などの弱いハッシュアルゴリズムの利用を制御することが可能となる。
また、Cipher Suiteを構成する個々のアルゴリズムについても、暗号強度に基づく安全性に関する基準を満たすか否かをアルゴリズムごとに個別に判定する。したがって、暗号化通信の先立って行われるハンドシェイクの際に、安全でないハッシュアルゴリズムが利用されることを抑制することができる。よって、暗号化通信に利用される全てのアルゴリズムが所定の条件（安全性基準）を満たすもののみに限定することが可能となる。
本実施形態では、暗号化通信部６０２が、ClientHelloを受信した後に、弱い暗号の利用を禁止する設定を確認する（ステップＳ８０２）。この確認の結果、弱い暗号の利用を禁止する設定が有効である場合に、Cipher Suiteの利用を制限するための処理（ステップＳ８０３）を実行する。しかしながら、ステップＳ８０３を実行するタイミングはこれに限定されるものではない。例えば、複合機４０１の起動時に実行してもよい。また、ステップＳ８０３によって制限されるCipher Suiteを予め静的に管理してもよい。
また、本実施形態のように、ステップＳ９０２の処理で利用が禁止されないと判定されたCipher SuiteについてステップＳ９０４の処理を行うようにすれば、判定処理の数が多いステップＳ９０３を省略できる場合があるので好ましい。しかしながら、ステップＳ９０４の処理で利用が禁止されないと判定されたCipher Suiteについて、ステップＳ９０２の処理を行うようにしてもよい。
また、図１１に示す例では、「サーバ認証アルゴリズム」、「鍵交換アルゴリズム」、「暗号化アルゴリズム」、「MACの計算に利用するハッシュアルゴリズム」の順番で、Cipher Suiteを構成するアルゴリズムを選択した。しかしながら、アルゴリズムを選択する順番は、図１１に示す順番に限定されない。
（第２の実施形態）
以上のように、第１の実施形態では、SSL/TLS（SSLまたはTLS）を利用した場合に、弱いハッシュアルゴリズムが署名に利用されることを抑制する場合を例に挙げて説明した。ところで、SSLを利用した場合、非特許文献１に記載されていないMACアルゴリズムが利用されてしまうという場合がある。具体的には、Fininshedメッセージで利用されるMACアルゴリズムにおいて、TLSではHMACが利用されるのに対し、SSLでは、HMACではないアルゴリズムが利用される。ここで、HMACではないアルゴリズムは、HMACと厳密には計算方法が異なるアルゴリズムであって、非特許文献１に未記載のアルゴリズムをいう。尚、以下の説明では、Fininshedメッセージを、必要に応じてFinishedと略称する。
そこで、本実施形態では、暗号化通信において、非特許文献１に記載されていないMACアルゴリズムが利用されないための制御を行う場合を例に挙げて説明する。このように本実施形態は、第１の実施形態に対し、SSLの利用を制限するための処理が追加されたものである。したがって、本実施形態の説明において、第１の実施形態と同一の部分については、図１～図１２に付した符号と同一の符号を付す等して、詳細な説明を省略する。
図１３は、複合機４０１の処理の一例を説明するフローチャートである。
ステップＳ１３０１、Ｓ１３０２の処理は、それぞれ、第１の実施形態で説明した図８のステップＳ８０１、Ｓ８０２の処理と同じであるため、その詳細な説明を省略する。
ステップＳ１３０２の判定の結果、弱い暗号の利用を禁止する設定が有効でない場合には、ステップＳ１３０８に進む。ステップＳ１３０８に進むと、暗号制御部６０６は、複合機４０１に設定されているCipher Suiteの優先度順において、優先度の最も高いCipherSuiteを選択し、ステップＳ１３０６に進む。ステップＳ１３０６に進むと、暗号化通信部６０２は、SSL/TLSによる暗号化通信を実行する。この場合には、SSLを使用することができる。また、Cipher Suiteは制限されない。
一方、ステップＳ１３０２の判定の結果、弱い暗号の利用を禁止する設定が有効である場合には、ステップＳ１３０３に進む。ステップＳ１３０３に進むと、暗号制御部６０６は、プロトコル禁止処理を行う。本実施形態では、暗号制御部６０６は、SSL自体の利用を禁止する。
次に、ステップＳ１３０４において、暗号制御部６０６は、禁止処理を行う。本実施形態では、暗号制御部６０６は、TLSによる暗号化通信に利用可能なCipher Suiteを禁止する処理を行う。ステップＳ１３０４の処理は、第１の実施形態で説明した図８のステップＳ８０３（図９～図１１）の処理と同じであるため、その詳細な説明を省略する。
次に、ステップＳ１３０５において、暗号制御部６０６は、利用が許可されているCipher Suiteを取得する。
次に、ステップＳ１３０６において、暗号制御部６０６は、複合機４０１に設定されているCipher Suiteの優先度順において、優先度の最も高いCipher Suiteを選択する。
次に、ステップＳ１３０７において、暗号化通信部６０２は、ステップＳ１３０６で選択されたCipher Suiteを用いて、TLSによる暗号化通信を実行する。
以上のように本実施形態では、弱い暗号の利用を禁止する設定が複合機４０１に適用されている場合に、SSLの利用を禁止し、その後、TLSによる暗号化通信で利用するCipher Suiteを制限する。したがって、第１の実施形態で説明した効果に加え、Fininshedメッセージで利用されるMACアルゴリズムとして、非特許文献１に未記載の弱いアルゴリズムが利用されることを抑制するという効果が得られる。
本実施形態においても、第１の実施形態で説明した変形例を適用することができる。例えば、本実施形態では、暗号化通信部６０２が、ネットワークＩ／Ｆ５０１を介して、ClientHelloを受信した後に、弱い暗号の利用を禁止する設定を確認する（ステップＳ１３０２）。この確認の結果、弱い暗号の利用を禁止する設定が有効である場合に、SSLの利用の禁止と、Cipher Suiteの利用の制限を行うための処理（ステップＳ１３０３、Ｓ１３０４）を実行する。しかしながら、ステップＳ１３０３、Ｓ１３０４を実行するタイミングはこれに限定されるものではない。例えば、複合機４０１の起動時に実行してもよい。また、ステップＳ１３０４によって制限されるTLSのCipher Suiteを予め静的に管理してもよい。
また、本実施形態のように、図１３のステップＳ１３０３において、SSLの利用を禁止した上で、ステップＳ１３０４において、TLSのみのCipher Suiteの利用を制限する処理を行うようにすれば、計算の負荷を低減できるので好ましい。しかしながら、例えば、ステップＳ１３０３とステップＳ１３０４の順番を逆にしてもよい。この場合、ステップＳ１３０４では、SSLとTLSの双方のCipher Suiteについての利用を制限する処理を行うことになる。
（第３の実施形態）
第１の実施形態では、SSL/TLSによる暗号化通信を行うサーバが複合機４０１であり、複合機４０１が、受信したClientHelloの情報に応じて、Cipher Suiteで利用する鍵交換の方法を制御する場合を例に挙げて説明した。これに対し、本実施形態では、複合機４０１がクライアントの場合の制御について説明する。このように本実施形態と第１の実施形態とは、複合機４０１がクライアントであることによる構成及び処理が主として異なる。したがって、本実施形態の説明において、第１の実施形態と同一の部分については、図１～図１２に付した符号と同一の符号を付す等して、詳細な説明を省略する。
以下、図１４のフローチャートを用いて、複合機４０１がクライアントの場合の制御の一例を説明する。
まず、ステップＳ１４０１において、暗号化通信部６０２は、ネットワークＩ／Ｆ５０１を介して、ClientHelloメッセージを送信するタイミングになるまで待機する。
次に、ステップＳ１４０２において、暗号制御部６０６は、設定値管理部６０４により管理されている前記設定値を参照することで、弱い暗号の利用を禁止する設定が有効であるか否かを判定する。
この判定の結果、弱い暗号の利用を禁止する設定が有効でない場合には、ステップＳ１４０７に進む。この場合、暗号制御部６０６はCipher Suiteや暗号化通信プロトコルを制限しない。そして、ステップＳ１４０７において、暗号化通信部６０２は、SSL/TLSによ
る暗号化通信を実行する。
一方、弱い暗号の利用を禁止する設定が有効である場合には、ステップＳ１４０３に進む。ステップＳ１４０３に進むと、暗号制御部６０６は、SHA2のみを利用可とするSignature Algorithms extensionをClientHelloメッセージに設定する。そして、ステップＳ１
４０４において、暗号制御部６０６は、Cipher Suiteの利用を制限する処理を行う。
ここで、ステップＳ１４０４の処理（Cipher Suiteの利用を制限する処理）の一例を、図１５のフローチャートを用いて説明する。
図１５のステップＳ１５０１において、暗号制御部６０６は、チェック対象のCipher Suiteに含まれる暗号化アルゴリズムがＡＥＳであるか否かを判定する。この判定の結果、暗号化アルゴリズムがＡＥＳである場合には、後述するステップＳ１５０３に進む。
一方、暗号化アルゴリズムがＡＥＳでない場合には、ステップＳ１５０２に進む。ステップＳ１５０２に進むと、暗号制御部６０６は、チェック対象のCipher Suiteに含まれる暗号化アルゴリズムが３ＴＤＥＳであるか否かを判定する。この判定の結果、暗号化アルゴリズムが３ＴＤＥＳでない場合にはステップＳ１５０５に進む。ステップＳ１５０５に進むと、暗号制御部６０６はチェック対象のCipher Suiteの利用を禁止する。
一方、暗号化アルゴリズムが３ＴＤＥＳである場合には、ステップＳ１５０３に進む。
ステップＳ１５０３に進むと、暗号制御部６０６は、チェック対象のCipher Suiteに含まれるＭＡＣの計算に利用するハッシュアルゴリズムがＳＨＡ１であるか否かを判定する。この判定の結果、ＭＡＣの計算に利用するハッシュアルゴリズムがＳＨＡ１である場合にはステップＳ１５０６に進む。
一方、ＭＡＣの計算に利用するハッシュアルゴリズムがＳＨＡ１でない場合には、ステップＳ１５０４に進む。ステップＳ１５０４に進むと、暗号制御部６０６は、チェック対象のCipher Suiteに含まれるＭＡＣの計算に利用するハッシュアルゴリズムがＳＨＡ２であるか否かを判定する。この判定の結果、ＭＡＣの計算に利用するハッシュアルゴリズムがＳＨＡ２である場合にはステップＳ１５０６に進む。
一方、ＭＡＣの計算に利用するハッシュアルゴリズムがＳＨＡ２でない場合には、ステップＳ１５０５に進む。ステップＳ１５０５に進むと、暗号制御部６０６は、チェック対象のCipher Suiteの利用を禁止しステップＳ１５０６に進む。
ステップＳ１５０６では、暗号制御部６０６は、暗号化通信部６０２がサポートする全てのCipher Suiteに対して、暗号化アルゴリズムの判定と、ＭＡＣに利用するハッシュアルゴリズムの判定を終了したか否かを判定する。尚、暗号化アルゴリズムの判定は、ステップＳ１５０１、Ｓ１５０２による判定であり、ＭＡＣに利用するハッシュアルゴリズムの判定は、ステップＳ１５０３、Ｓ１５０４による判定である。
この判定の結果、全てのCipher Suiteに対する判定が終了していない場合には、全てのCipher Suiteに対して前述したステップＳ１５０１～Ｓ１５０５の処理を実行する。処理を実行するCipher Suiteの順番としては、例えば、複合機４０１に設定されているCipherSuiteの優先度順が挙げられる。しかしながら、かかる順番はこれに限定されるものではない。
以上のようにして図１５のフローチャートによる処理（ステップＳ１４０４の処理）が終了すると、ステップＳ１４０５に進む。ステップＳ１４０５に進むと、暗号化通信部６０２は、ステップ１４０４でのCipher Suiteの利用の制限を受けなかった（つまり利用の許可がされている）Cipher Suiteを取得する。
その後、ステップＳ１４０６において、暗号化通信部６０２は、ＴＬＳによる暗号化通信を実行する。
以上のように本実施形態では、弱い暗号の利用を禁止する設定がクライアントである複合機４０１に適用されている場合について説明した。複合機４０１は、クライアントとして暗号化通信を行う際には、ＳＨＡ２のみを利用可能とするSingature Algorithms extensionをClient Helloメッセージに設定する。これにより、ServerKeyExchangeを必要とする鍵交換であっても、強いハッシュアルゴリズムを利用して暗号化通信を行うことが可能となる。
本実施形態においても、第１の実施形態で説明した変形例を適用することができる。
尚、前述した各実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
（その他の実施形態）
本発明は、前述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
４０１：複合機、４０２：ＰＣ、４０３：ネットワーク

Claims (9)

  1. 特定の暗号化通信プロトコルに従って外部装置と暗号化通信を行う情報処理装置であって、
    前記暗号化通信プロトコルで使用されるアルゴリズムのセットが、暗号強度に基づく安全性に関する基準とは異なる所定の条件を満たすか否かを判定することによって、当該アルゴリズムのセットが、利用が禁止されるアルゴリズムのセットであるか否かを、前記暗号化通信プロトコルで使用される複数のアルゴリズムのセットのそれぞれについて判定し、前記利用が禁止されないと判定したアルゴリズムのセットについて、暗号強度に基づく安全性に関する基準を満たすか否かを判定することを、前記複数のアルゴリズムを順番に選択して行う判定手段と、
    前記暗号化通信プロトコルで使用される複数のアルゴリズムのセットのうち、前記判定手段により前記所定の条件を満たさずに利用が禁止されると判定されたアルゴリズムのセットの利用と、前記判定手段により暗号強度に基づく安全性に関する基準を満たさないと判定されたアルゴリズムのセットの利用とを禁止する禁止手段と、
    前記複数のアルゴリズムのセットのうち、前記禁止手段により利用が禁止されないアルゴリズムのセットを利用して、前記暗号化通信に先立って前記外部装置との間で行われるハンドシェイクと前記暗号化通信とを行う通信手段と、を有し、
    前記禁止手段により利用が禁止されるアルゴリズムのセットは、前記ハンドシェイクの際に、前記情報処理装置の署名付きのメッセージを、前記外部装置に送信する必要があるアルゴリズムのセットであり、
    前記禁止手段により利用が禁止されるアルゴリズムのセットと、前記禁止手段により利用が禁止されないアルゴリズムのセットは、前記情報処理装置の認証のためのアルゴリズムを含み、
    前記暗号強度に基づく安全性に関する基準は、前記情報処理装置の証明書に対する署名に利用されるハッシュアルゴリズムの安全性に関する基準と、前記情報処理装置の証明書における公開鍵の安全性に関する基準と、の少なくとも何れか１つを含むことを特徴とする情報処理装置。
  2. 所定の暗号強度の暗号化通信を禁止する設定に従って、前記禁止手段により、前記暗号化通信プロトコルで使用される複数のアルゴリズムのセットのうち、前記所定の条件を満たさないアルゴリズムのセットの利用が禁止されることを特徴とする請求項１に記載の情報処理装置。
  3. 前記暗号強度に基づく安全性に関する基準は、前記アルゴリズムのセットを構成するアルゴリズムで使用される暗号鍵のサイズに関する基準と、前記アルゴリズムのセットを構成するアルゴリズムの名称に関する基準と、の少なくとも何れか１つを含むことを特徴とする請求項１または２に記載の情報処理装置。
  4. 前記利用が禁止されるアルゴリズムのセットは、ハンドシェイクの際にサーバの署名つきのメッセージをサーバからクライアントに送信する必要があるアルゴリズムのセットを含み、
    前記利用が許可されるアルゴリズムのセットは、ハンドシェイクの際にサーバの公開鍵を用いて暗号鍵を交換するアルゴリズムのセットを含むことを特徴とする請求項１～３の何れか１項に記載の情報処理装置。
  5. 前記特定の暗号化通信プロトコルは、SSL(Secure Socket Layer)またはTLS(Transport Layer Security)であることを特徴とする請求項１～４の何れか１項に記載の情報処理装置。
  6. 複数の前記特定の暗号化通信プロトコルのうち、予め定められているアルゴリズムを使用する暗号化通信プロトコルの利用を禁止するプロトコル禁止手段を更に有し、
    前記通信手段は、前記禁止手段と前記プロトコル禁止手段により利用が禁止されないアルゴリズムのセットを利用して、前記ハンドシェイクと前記暗号化通信とを行うことを特徴とする請求項１～５の何れか１項に記載の情報処理装置。
  7. 前記判定手段は、複数の前記特定の暗号化通信プロトコルのうち、前記プロトコル禁止手段により利用が禁止されなかった暗号化通信プロトコルで使用される複数のアルゴリズムのセットが、前記利用が禁止されるアルゴリズムのセットであるか否かを、当該複数のアルゴリズムのセットのそれぞれについて判定することを特徴とする請求項６に記載の情報処理装置。
  8. 特定の暗号化通信プロトコルに従って情報処理装置と外部装置とにより暗号化通信を行う暗号化通信方法であって、
    前記暗号化通信プロトコルで使用されるアルゴリズムのセットが、暗号強度に基づく安全性に関する基準とは異なる所定の条件を満たすか否かを判定することによって、当該アルゴリズムのセットが、利用が禁止されるアルゴリズムのセットであるか否かを、前記暗号化通信プロトコルで使用される複数のアルゴリズムのセットのそれぞれについて判定し、前記利用が禁止されないと判定したアルゴリズムのセットについて、暗号強度に基づく安全性に関する基準を満たすか否かを判定することを、前記複数のアルゴリズムを順番に選択して行う判定工程と、
    前記暗号化通信プロトコルで使用される複数のアルゴリズムのセットのうち、前記判定工程により前記所定の条件を満たさずに利用が禁止されると判定されたアルゴリズムのセットの利用と、前記判定工程により暗号強度に基づく安全性に関する基準を満たさないと判定されたアルゴリズムのセットの利用とを禁止する禁止工程と、
    前記複数のアルゴリズムのセットのうち、前記禁止工程により利用が禁止されないアルゴリズムのセットを利用して、前記暗号化通信に先立って前記外部装置との間で行われるハンドシェイクと前記暗号化通信とを行う通信工程と、を有し、
    前記禁止工程により利用が禁止されるアルゴリズムのセットは、前記ハンドシェイクの際に、前記情報処理装置の署名付きのメッセージを、前記外部装置に弱いハッシュアルゴリズムを用いて送信する必要があるアルゴリズムのセットであり、
    前記禁止工程により利用が禁止されるアルゴリズムのセットと、前記禁止工程により利用が禁止されないアルゴリズムのセットは、前記情報処理装置の認証のためのアルゴリズムを含み、
    前記暗号強度に基づく安全性に関する基準は、前記情報処理装置の証明書に対する署名に利用されるハッシュアルゴリズムの安全性に関する基準と、前記情報処理装置の証明書における公開鍵の安全性に関する基準と、の少なくとも何れか１つを含むことを特徴とする暗号化通信方法。
  9. 特定の暗号化通信プロトコルに従って情報処理装置と外部装置とにより暗号化通信を行うための処理をコンピュータに実行させるためのプログラムであって、
    前記暗号化通信プロトコルで使用されるアルゴリズムのセットが、暗号強度に基づく安全性に関する基準とは異なる所定の条件を満たすか否かを判定することによって、当該アルゴリズムのセットが、利用が禁止されるアルゴリズムのセットであるか否かを、前記暗号化通信プロトコルで使用される複数のアルゴリズムのセットのそれぞれについて判定し、前記利用が禁止されないと判定したアルゴリズムのセットについて、暗号強度に基づく安全性に関する基準を満たすか否かを判定することを、前記複数のアルゴリズムを順番に選択して行う判定手段と、
    前記暗号化通信プロトコルで使用される複数のアルゴリズムのセットのうち、前記判定手段により前記所定の条件を満たさずに利用が禁止されると判定されたアルゴリズムのセットの利用と、前記判定手段により暗号強度に基づく安全性に関する基準を満たさないと判定されたアルゴリズムのセットの利用とを禁止する禁止手段と、
    前記複数のアルゴリズムのセットのうち、前記禁止手段により利用が禁止されないアルゴリズムのセットを利用して、前記暗号化通信に先立って前記外部装置との間で行われるハンドシェイクと前記暗号化通信とを行うための処理を行う通信手段としてコンピュータを機能させ、
    前記禁止手段により利用が禁止されるアルゴリズムのセットは、前記ハンドシェイクの際に、前記情報処理装置の署名付きのメッセージを、前記外部装置に送信する必要があるアルゴリズムのセットであり、
    前記禁止手段により利用が禁止されるアルゴリズムのセットと、前記禁止手段により利用が禁止されないアルゴリズムのセットは、前記情報処理装置の認証のためのアルゴリズムを含み、
    前記暗号強度に基づく安全性に関する基準は、前記情報処理装置の証明書に対する署名に利用されるハッシュアルゴリズムの安全性に関する基準と、前記情報処理装置の証明書における公開鍵の安全性に関する基準と、の少なくとも何れか１つを含むことを特徴とするプログラム。
JP2020051239A 2014-07-16 2020-03-23 情報処理装置、暗号化通信方法、およびプログラム Active JP7087015B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2014146030 2014-07-16
JP2014146030 2014-07-16

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2015002657A Division JP2016029787A (ja) 2014-07-16 2015-01-08 情報処理装置、暗号化通信方法、およびプログラム

Publications (2)

Publication Number Publication Date
JP2020114002A JP2020114002A (ja) 2020-07-27
JP7087015B2 true JP7087015B2 (ja) 2022-06-20

Family

ID=55075554

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2015002657A Pending JP2016029787A (ja) 2014-07-16 2015-01-08 情報処理装置、暗号化通信方法、およびプログラム
JP2020051239A Active JP7087015B2 (ja) 2014-07-16 2020-03-23 情報処理装置、暗号化通信方法、およびプログラム

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2015002657A Pending JP2016029787A (ja) 2014-07-16 2015-01-08 情報処理装置、暗号化通信方法、およびプログラム

Country Status (2)

Country Link
US (2) US9807084B2 (ja)
JP (2) JP2016029787A (ja)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10567434B1 (en) 2014-09-10 2020-02-18 Amazon Technologies, Inc. Communication channel security enhancements
US10374800B1 (en) 2014-09-10 2019-08-06 Amazon Technologies, Inc. Cryptography algorithm hopping
US9923923B1 (en) * 2014-09-10 2018-03-20 Amazon Technologies, Inc. Secure transport channel using multiple cipher suites
SG11201702438VA (en) * 2014-09-25 2017-04-27 Nec Corp Analysis system, analysis device, analysis method, and storage medium having analysis program recorded therein
US10122689B2 (en) 2015-06-16 2018-11-06 Amazon Technologies, Inc. Load balancing with handshake offload
US9893883B1 (en) * 2015-06-26 2018-02-13 Juniper Networks, Inc. Decryption of secure sockets layer sessions having enabled perfect forward secrecy using a diffie-hellman key exchange
US10305871B2 (en) * 2015-12-09 2019-05-28 Cloudflare, Inc. Dynamically serving digital certificates based on secure session properties
JP6881935B2 (ja) 2016-10-07 2021-06-02 キヤノン株式会社 通信装置、通信装置の制御方法及びプログラム
US11063758B1 (en) * 2016-11-01 2021-07-13 F5 Networks, Inc. Methods for facilitating cipher selection and devices thereof
JP6921530B2 (ja) * 2016-12-28 2021-08-18 キヤノン株式会社 情報処理装置及びその制御方法、並びにプログラム
DE102017202002A1 (de) * 2017-02-08 2018-08-09 Siemens Aktiengesellschaft Verfahren und Computer zum kryptografischen Schützen von Steuerungskommunikation in und/oder Service-Zugang zu IT-Systemen, insbesondere im Zusammenhang mit der Diagnose und Konfiguration in einem Automatisierungs-, Steuerungs- oder Kontrollsystem
US10764328B2 (en) * 2017-11-03 2020-09-01 International Business Machines Corporation Altering cipher and key within an established session

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011221893A (ja) 2010-04-13 2011-11-04 Sony Corp 情報処理装置、情報処理方法およびプログラム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6598167B2 (en) * 1997-09-26 2003-07-22 Worldcom, Inc. Secure customer interface for web based data management
CN1172469C (zh) * 2001-12-13 2004-10-20 华为技术有限公司 一种自主选择加密算法实现保密通信的方法
JP4714482B2 (ja) * 2005-02-28 2011-06-29 株式会社日立製作所 暗号通信システムおよび方法
JP2009094676A (ja) 2007-10-05 2009-04-30 Kyocera Mita Corp 画像形成装置
JP5456015B2 (ja) 2011-12-28 2014-03-26 キヤノン株式会社 ２次元コードを用いて出力を制御可能な装置、その制御方法、プログラム。
EP2999157B1 (en) * 2013-05-16 2017-02-22 Fujitsu Limited Terminal device, communication system, and communication control program

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011221893A (ja) 2010-04-13 2011-11-04 Sony Corp 情報処理装置、情報処理方法およびプログラム

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
DIERKS, T., RESCORLA, E.，The Transport Layer Security (TLS) Protocol Version 1.2，RFC 5246，[online]，2008年08月，https://tools.ietf.org/html/rfc5246，[2018年9月25日検索]
How to Disable Weak Ciphers and SSL 2.0 in Apache，[online]，2010年12月，https:web.aruchive.org/web/20101215110055/https://www.sslshopper.com/article-ho-to-disable-weak-ciphers-and-ssl-2.0-in-apach.html，[2018年9月25日検索]
LAURIE, B., LAURIE, P.，Apacheハンドブック 第3版，株式会社オライリー・ジャパン，2003年09月24日，p.1-5,286,287,295-301
POLK, T., McKAY, K. and CHOKHANI, S.，Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementatio，NIST Special Publication，800-52, Revision 1，2014年04月，http://dx.doi.org/10.6028/NIST.SP.800-52r1，[2018年9月25日検索]
高野誠士，関良明，諏訪博彦，個人ユーザ向けＨＴＴＰＳ暗号危殆化確認サービスの受容性評価，電子情報通信学会論文誌，2014年05月01日，第J97-D巻 第5号，p.975-983

Also Published As

Publication number Publication date
US10230716B2 (en) 2019-03-12
US20180034807A1 (en) 2018-02-01
US20160021110A1 (en) 2016-01-21
JP2016029787A (ja) 2016-03-03
US9807084B2 (en) 2017-10-31
JP2020114002A (ja) 2020-07-27

Similar Documents

Publication Publication Date Title
JP7087015B2 (ja) 情報処理装置、暗号化通信方法、およびプログラム
CN109088889B (zh) 一种ssl加解密方法、系统及计算机可读存储介质
EP3210335B1 (en) Efficient start-up for secured connections and related services
US11533297B2 (en) Secure communication channel with token renewal mechanism
EP2997693B1 (en) Secure session capability using public-key cryptography without access to the private key
JP6348661B2 (ja) サードパーティの認証サポートを介した企業認証
TWI605383B (zh) 列印機與列印用戶端裝置之間的安全列印技術
CN107800675B (zh) 一种数据传输方法、终端以及服务器
EP3065334A1 (en) Key configuration method, system and apparatus
EP1855223A1 (en) Extending the DRM realm to external devices
JP5511463B2 (ja) 画像形成装置、画像処理システム、画像処理システムを制御する方法、およびプログラム
US20180034643A1 (en) SSL Gateway with Integrated Hardware Security Module
JP2015115893A (ja) 通信方法、通信プログラム、および中継装置
CN108809907B (zh) 一种证书请求消息发送方法、接收方法和装置
US10291600B2 (en) Synchronizing secure session keys
Housley Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms
EP3026594B1 (en) Cryptographic security profiles
JP2006018399A (ja) 情報処理装置、情報処理方法およびプログラム
JP2013156757A (ja) ネットワークに接続する機器、機器の制御方法、及びプログラム
JP6679867B2 (ja) 通信システム、通信装置、および、コンピュータプログラム
CN109246156B (zh) 登录认证方法及装置、登录方法及装置以及登录认证系统
US10992741B2 (en) System and method for providing a configuration file to client devices
US11425122B2 (en) System and method for providing a configuration file to client devices
EP2887247B1 (en) Information processing apparatus, information processing method and program
JP6921530B2 (ja) 情報処理装置及びその制御方法、並びにプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200402

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210622

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210823

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220201

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220325

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220510

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220608

R151 Written notification of patent or utility model registration

Ref document number: 7087015

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151