KR100862264B1 - 검사 장치, 통신 시스템, 검사 방법, 컴퓨터-실행가능한프로그램 제품 및 컴퓨터-판독가능한 기록 매체 - Google Patents

Abstract

수신 수단, 취득 수단, 및 검사 수단을 포함하는 검사 장치가 제공된다. 수신 수단은, 공개키 암호를 이용한 인증 처리를 하지만 그 인증 처리에 사용하는 공개키 증명서는 특정한 통신 상대에게만 건네는 통신 장치로부터, 상기 통신 장치의 공개키 증명서와 상기 통신 장치의 식별 정보를 수신하고, 취득 수단은, 수신 수단이 수신한 식별 정보에 대응하는 공개키 증명서의 내용을 나타내는 정보를, 상기 식별 정보를 바탕으로, 통신 장치와는 다른 장소로부터 취득하며, 검사 수단은, 취득 수단이 취득한 정보를 참조하여, 수신 수단이 수신한 공개키 증명서가 적절한 것인지의 여부에 기초하여 상기 통신 장치를 검사한다.

Description

검사 장치, 통신 시스템, 검사 방법, 컴퓨터-실행가능한 프로그램 제품 및 컴퓨터-판독가능한 기록 매체{EXAMINATION APPARATUS, COMMUNICATION SYSTEM, EXAMINATION METHOD, COMPUTER-EXECUTABLE PROGRAM PRODUCT, AND COMPUTER-READABLE RECORDING MEDIUM}

본 발명은, 검사 장치, 통신 시스템, 검사 방법, 컴퓨터-실행가능한 프로그램 제품 및 컴퓨터-판독가능한 기록 매체에 관한 것으로, 더 구체적으로는, 공개키 암호를 이용한 인증 처리를 하는 통신 장치를 검사하는 검사 장치 및 검사 방법, 검사 대상의 통신 장치를 검사하기 위한 검사 장치를 포함한 통신 시스템, 및 통신 장치를 검사하는 검사 장치로서 컴퓨터를 기능시키기 위한 컴퓨터-실행가능한 프로그램 제품, 및 통신 장치를 검사하는 검사 장치로서 컴퓨터를 기능시키기 위한 컴퓨터-실행가능한 프로그램을 기록한 컴퓨터-판독가능한 기록 매체에 관한 것이다.

종래부터, 각각 통신 기능을 갖춘 복수의 통신 장치를 네트워크를 통해 통신 가능하게 접속하여, 여러 가지 시스템을 구축하는 것이 이루어지고 있다. 그 일례로서는, 클라이언트 장치로서 기능하는 PC(퍼스널 컴퓨터) 등의 컴퓨터가 상품 주문을 송신하고, 인터넷을 통해 클라이언트 터미널에 접속된 서버 장치가 그 주문을 접수하는, 소위 "전자 상거래 시스템"을 들 수 있다. 또한, 여러 가지 전자 장치 에 클라이언트 장치 또는 서버 장치의 기능을 구현하고, 네트워크를 통해 접속시켜, 상호간의 통신에 의해서 전자 장치의 원격 관리를 하는 시스템도 제안되어 있다.

이러한 시스템을 구축하기 위해, 통신을 할 때에, 통신 상대가 적절한지 또는 통신 상태로부터 송신되어 오는 정보가 위조되어 있지는 않은지와 같은 확인이 중요하다. 또한, 특히 인터넷에 있어서는, 정보가 통신 상대에게 도달할 때까지 무관계한 컴퓨터를 경유하는 경우가 많으므로, 기밀 정보를 송신하는 경우, 그 내용을 훔쳐보지 않도록 할 필요도 있다. 그리고, 이러한 요구에 부응하는 통신 프로토콜로서, 예컨대 SSL(Secure Socket Layer)이라 불리는 프로토콜이 개발되어 있어, 널리 이용되고 있다. 이 프로토콜을 이용하여 통신을 함으로써, 공개키 암호 방식과 공통 키 암호 방식을 조합하여, 통신 상대의 인증을 하는 동시에, 정보의 암호화에 의해 위조 및 도청 방지를 도모할 수 있다. 또한, 통신 상대측에서도, 통신을 요구해 온 통신원 장치를 인증할 수 있다.

이러한 SSL이나 공개키 암호를 이용한 인증에 관련되는 기술로서는 예컨대 일본 특허 공개 2002-353959호 공보, 및 일본 특허 공개 2002-251492호 공보에 기재된 것을 들 수 있다.

여기서, 이 SSL에 따른 상호 인증을 하는 경우의 통신 순서에 대해서, 인증 처리 부분에 초점을 맞춰 설명한다. 도 1은 통신 장치 A와 통신 장치 B가 SSL에 따른 상호 인증을 할 때에 각 장치에 있어서 실행하는 처리의 흐름도를, 그 처리에 이용하는 정보와 함께 도시한 도면이다.

도 1에 도시한 바와 같이, SSL에 따른 상호 인증을 할 때는, 우선 쌍방의 통신 장치에, 루트 키 증명서 및 개인키와 공개키 증명서의 조합을 기억시켜 놓을 필요가 있다. 이 개인키는 인증국(CA : Certificate Authority)이 각 장치에 대하여 발행한 개인키이며, 공개키 증명서는 그 개인키와 대응하는 공개키에 CA가 디지털 서명을 붙여 디지털 증명서로 한 것이다. 또한, 루트 키 증명서는 CA가 디지털 서명에 이용한 루트 개인키와 대응하는 루트 키에, 디지털 서명을 붙여 디지털 증명서로 한 것이다.

도 2a 및 2b에 이들의 관계를 도시한다.

도 2a에 도시한 바와 같이, 공개키 A는 개인키 A를 이용하여 암호화된 문서를 복호화하기 위한 키 본체와, 그 공개키의 발행자(CA)나 유효 기간 등의 정보를 포함하는 서지 정보에 의해 구성된다. 그리고, CA는 키 본체나 서지 정보가 위조되어 있지 않음을 나타내기 위해서, 공개키 A를 해시 처리하여 얻은 해시값을, 루트 개인키를 이용하여 암호화하여, 디지털 서명으로서 클라이언트 공개키에 붙인다. 또한 이 때에, 디지털 서명에 이용하는 루트 개인키의 식별 정보를 서명 키 정보로서 공개키 A의 서지 정보에 더한다. 그리고, 이 디지털 서명을 붙인 공개키 증명서가 공개키 증명서 A이다.

이 공개키 증명서 A를 인증 처리에 이용하는 경우에는, 공개키 증명서 A에 포함되는 디지털 서명을, 루트 공개키에 대응하는 공개키인 루트 키의 키 본체를 이용하여 복호화한다. 이 복호화가 정상적으로 이루어지면, 디지털 서명이 확실하게 CA에 의해서 첨부되었음을 알 수 있다. 또한, 공개키 A의 부분을 해시 처리하여 얻은 해시값과, 복호하여 얻은 해시값이 일치하면, 키 자체도 손상이나 위조를 받고 있지 않음을 알 수 있다.

또한, 수신한 데이터를 공개키 A를 이용하여 정상적으로 복호화할 수 있으면, 그 데이터는 개인키 A의 주인으로부터 송신되었음을 알 수 있다.

여기서, 인증을 하기 위해서는, 루트 키를 미리 기억해 놓아야 하는데, 이 루트 키도 도 2b에 도시한 바와 같이, CA가 디지털 서명을 붙인 루트 키 증명서로서 기억해 둔다. 이 루트 키 증명서는 자신에 포함되는 공개키로 디지털 서명을 복호화할 수 있는, 자기-서명 형식(self-signature format)이다. 그리고, 루트 키를 사용할 때에, 그 루트 키 증명서에 포함되는 키 본체를 이용하여 디지털 서명을 복호화하고, 루트 키를 해시 처리하여 얻은 해시값과 비교한다. 루트키가 해시값과 일치하면, 루트 키가 파손되거나 하지 않음을 확인할 수 있는 것이다.

도 1에 도시된 흐름도 각각이 설명될 것이다. 한편, 이 도면에 있어서, 2개 흐름도 사이의 화살표는 데이터의 전송을 나타내며, 송신측은 화살표의 근원의 단계에서 전송 처리를 하고, 수신측은 그 정보를 수신하면 화살표의 끝단의 단계를 처리하는 것으로 한다. 또한, 각 단계의 처리가 정상적으로 완료되지 않은 경우에는, 그 시점에서 인증 실패의 응답을 회신하고 처리를 중단하는 것으로 한다. 상대로부터 인증 실패의 응답을 받은 경우, 처리가 시간 초과된 경우 등도 마찬가지이다.

여기서는, 통신 장치 A가 통신 장치 B에 통신을 요구하는 것으로 하는데, 이 요구를 하는 경우, 통신 장치 A의 CPU는 사전설정된 제어 프로그램을 실행함으로 써, 도 1의 좌측에 도시하는 흐름도의 처리를 시작한다. 그리고, 단계 S211에서 통신 장치 B에 대하여 접속 요구를 송신한다.

한편 통신 장치 B의 CPU는 이 접속 요구를 수신하면, 사전설정된 제어 프로그램을 실행함으로써, 도 1의 우측에 도시하는 흐름도의 처리를 시작한다. 그리고, 단계 S221에서 제1 난수를 생성하여, 이것을 개인키 B를 이용하여 암호화한다. 그리고, 단계 S222에서 그 암호화한 제1 난수와 공개키 증명서 B를 통신 장치 A에 송신한다.

통신 장치 A 측에서는, 암호화한 제1 난수와 공개키 증명서 B를 수신하면, 단계 S212에서 루트 키 증명서를 이용하여 공개키 증명서 B의 정당성을 확인한다.

정당성이 확인이 되면, 단계 S213에서, 수신한 공개키 증명서 B에 포함되는 공개키 B를 이용하여 제1 난수를 복호화한다. 여기서 제1 난수의 복호화가 성공하면, 제1 난수는 확실히 공개키 증명서 B의 발행 대상으로부터 수신한 것임을 확인할 수 있다.

그 후, 단계 S214에서 이것과는 달리 제2 난수 및 공통 키의 시드(seed)를 생성한다. 예컨대, 공통 키의 시드는 그때까지의 통신에서 주고받은 데이터에 기초하여 작성할 수 있다. 그리고, 단계 S215에서 제2 난수를 개인키 A를 이용하여 암호화하고, 공통 키의 시드를 공개키 B를 이용하여 암호화하여, 단계 S216에서 이들을 공개키 증명서 A와 함께 서버 장치에 송신한다. 공통 키의 시드의 암호화는, 통신 상대 이외의 장치에 공통 키의 시드가 알려지지 않도록 하기 위한 것이다.

또한, 다음 단계 S217에서는, 단계 S214에서 생성한 공통 키의 시드로부터 이후의 통신의 암호화에 이용하는 공통 키를 생성한다.

통신 장치 B 측에서는, 통신 장치 A가 단계 S216에서 송신하여 오는 데이터를 수신하면, 단계 S223에서, 루트 키 증명서를 이용하여 공개키 증명서 A의 정당성을 확인한다. 그리고 그 정당성이 확인되면, 단계 S224에서, 수신한 공개키 증명서 A에 포함되는 공개키 A를 이용하여 제2 난수를 복호화한다. 여기서 복호화가 성공하면, 제2 난수는 확실히 공개키 증명서 A의 발행 대상으로부터 수신한 것이라고 확인할 수 있다.

그 후, 단계 S225에서 개인키 B를 이용하여 공통 키의 시드를 복호화한다. 여기까지의 처리로, 통신 장치 A 측과 통신 장치 B 측에 공통 키의 시드가 공유된 것으로 된다. 그리고, 이 공통 키의 시드는 생성한 통신 장치 A와, 개인키 B를 갖는 통신 장치 B 이외의 장치가 알 수 있는 경우는 없다. 여기까지의 처리가 성공하면, 통신 장치 B 측에서도 단계 S226에서 복호화로 얻은 공통 키의 시드로부터 이후의 통신의 암호화에 이용하는 공통 키를 생성한다.

그리고, 통신 장치 A 측의 단계 S217과 통신 장치 B 측의 단계 S226의 처리가 종료되면, 서로 인증의 성공과 이후의 통신에 사용하는 암호화 방식을 확인하고, 생성한 공통 키를 이용하여 그 암호화 방식으로 이후의 통신을 하는 것으로 하고서 인증에 관한 처리를 종료한다. 한편, 이 확인에는 통신 장치 B로부터의 인증이 성공했다는 취지의 응답도 포함하는 것으로 한다. 이상의 처리에 의해서 상호 통신을 확립하고, 이후에는 단계 S217 또는 S226에서 생성한 공통 키를 이용하여, 공통 키 암호 방식으로 데이터를 암호화하여 통신을 할 수 있다.

이러한 처리를 함으로써, 통신 장치 A와 통신 장치 B가 서로 상대를 인증한 뒤에 안전하게 공통 키를 공유할 수 있어, 통신을 안전하게 행하는 경로를 확립할 수 있다.

한편, 한방향 인증을 채용하는 경우, 예컨대 통신 장치 B가 통신 요구원인 통신 장치 A를 인증하는 것만으로도 되는 것이라면, 도 1에 도시한 인증 처리에 있어서, 제1 난수의 암호화 및 송신을 생략할 수 있다. 이 경우라도, 공통 키의 시드를 통신 장치 A에서 통신 장치 B로 안전하게 송신하기 위해서, 통신 장치 B의 공개키 B를 이용한 암호화를 하면 좋지만, 공개키 B에 첨부된 디지털 서명의 정당성을 확인하는 것은 하지 않아도 된다. 그리고, 이 경우의 인증 처리는 도 3에 도시한 바와 같이 간략화된 것으로 된다. 즉, 통신 장치 A 측의 단계 S212 및 S213의 처리는 불필요하게 되고, 통신 장치 B 측의 단계 S221의 처리도 불필요하게 된다. 또한, 그 밖의 처리도 일부 간략화할 수 있다.

이상과 같은 인증 처리에 있어서는, 공개키로 암호화된 내용은 대응하는 개인키를 갖는 장치에서만 복호할 수 있고, 또한, 개인키로 암호화된 내용은 대응하는 공개키로만 복호할 수 있음을 이용하여, 통신 상대가 공개키 증명서에 그 발행처로서 기재되어 있는 장치라고(또는 그 장치의 이용자가 공개키 증명서에 그 발행처로서 기재되어 있는 이용자라고) 인증하게 된다.

한편, 이러한 인증 처리에 사용하는 공개키의 관리에 관한 기술로서는, 예컨대 일본 특허 공개 2003-348068호 공보(패러그래프 4), 및 일본 특허 공개 2002-190796호 공보에 기재된 기술이 알려져 있다.

일본 특허 공개 2003-348068호 공보에는, 사용자의 작업 부하를 경감시키기 위해 네트워크 상에 키 등록 장치를 구현하고 공개키를 관리하는 기술이 기재되어 있다.

일본 특허 공개 2002-190796호 공보에는, 전자 메일을 암호하하기 위해 공개키 암호화를 사용하는 경우에, 전자 메일 장치의 공개키 데이터베이스에만 필요한 공개키를 자동으로 등록하고 유효한 공개 키들만을 관리하도록 자동으로 관리하는 기술이 기재되어 있다.

그러나, 공개키 암호 방식에 있어서는, 키 길이에 따라 다르기도 하지만, 시간을 들이면 공개키로부터 개인키를 유도할 수 있다. 그리고, 개인키를 알아 버리면, 제3자가 그 개인키의 주인으로 위장하는 것이 가능하게 되기 때문에, 인증의 확실성이나 통신의 안전성이 유지되지 않는다. 그래서, 상술된 바와 같이 키에 유효 기한을 두어, 소정 기간마다 키 셋트를 갱신한다고 하는 시큐러티 정책을 채용하는 사용자가 증가하고 있다. 이 때문에, 예컨대 상기와 같은 상호 인증을 이용한 원격 관리 시스템 등을 제공하는 경우에는 고객에 대하여, 키의 갱신이 가능한 시스템이라는 보증을 할 필요가 생기고 있다.

그리고, 공개키 증명서를 이용하여 인증을 받는 통신 장치에 갱신용의 새로운 공개키 증명서를 배포하는 방식으로서는, 사용 중인 공개키 증명서의 유효 기한이 끊어지기 전에, CA가 통신 장치에 대하여 새로운 공개키 증명서와 개인키를 발행하여, 이들과 루트 키 증명서의 셋트를, CA 또는 그것을 대신하는 관리 장치가, 사용 중인 공개키 증명서를 이용하여 확립한 SSL에 의한 통신 경로로 갱신 대상의 장치에 송신하여 설정시키는 방식을 생각할 수 있다.

이와 같이 하면, 통신 장치가 인증에 사용하는 공개키 증명서 등을, 유효 기한이 끊어지기 전에 자동적으로 갱신할 수 있기 때문에, 사용자를 수고롭게 하지 않고서, 통신 장치를 인증 가능한 상태로 유지할 수 있다. 또한, 인터넷을 통해 송신을 하는 경우라도, 안전한 통신 경로를 확보하여 공개키 증명서 등의 전송을 할 수 있다.

그러나, SSL을 사용하여 통신 경로가 유지되더라도, 인터넷을 통한 통신의 경우, 몇개의 서버를 통해 정보가 전송되기 때문에, 전송 대상 정보의 도청(spying)이나 위조의 가능성이 완전히 제거되지는 않는다. 개인키가 도청되면, 위장(spoofing)이 가능하다. 따라서, 위험 가능성이 다소 적더라도 위장과 같은 위험을 제거하는 것이 바람직하다.

다만, 이러한 경우라도, 통신 장치에 CA나 관리 장치와의 사이에서 비상용의 통신 경로를 확보하는 수단을 마련해 두면, 통신 장치가 그 경로를 통해서 통상의 통신 경로를 확립하기 위한 새로운 공개키 증명서 등을 취득할 수 있도록 하는 것도 가능하다. 이러한 비상용의 통신 경로로서는 예컨대, 유효 기한이 긴 공개키 증명서 및 이것과 대응하는 개인키나 루트 키 증명서를, 벤더가 제공하는 각 장치에 공통으로 기억시켜 두고, 이들을 이용하여 CA나 관리 장치와의 사이에서 SSL에 의한 통신 경로를 확립할 수 있도록 하는 것을 생각할 수 있다.

이러한 기술에 관해서, 본 출원인은 과거에 특허출원을 했다(일본 특허 출원 2003-341329, 미공개).

그러나, 이러한 비상용의 통신 경로는 평소에는 사용하지 않는 것이며, 또한 통상의 통신 경로에서의 통신에 문제점이 있는 경우라도 통신이 가능하도록 할 필요가 있기 때문에, 통상의 통신 경로의 경우와 같은 엄밀함으로 인증 처리를 할 수 있도록 하는 것은 어렵다. 예컨대, 상기한 바와 같이 각 장치에 공통적인 공개키 증명서를 기억시키는 경우에는, 공개키 증명서에 장치의 식별 정보를 기재할 수는 없기 때문에, SSL에 의한 인증 처리의 시점에서는 장치의 식별 정보를 참조할 수 없다. 그리고, CA나 관리 장치는 통신 경로의 확립 후에 통신 장치에 식별 정보를 송신시켜, 그 정보를 믿고서 갱신용의 공개키 증명서 등의 송신을 하게 된다.

따라서, 비상용의 통신 경로는 다른 통신 장치로 위장하여 갱신용의 공개키 증명서를 취득하는 것이 비교적 간단하게 가능하게 되어 버린다고 하는 문제가 있었다. 그래서, 비상용의 통신 경로를 사용하는 경우, 즉 통상의 통신 경로를 사용할 수 없는 경우라도, 위장을 효과적으로 방지할 수 있도록 할 것이 요구되고 있었다.

이 점에 관해, 상술한 각 특허문헌에서는 통상 사용하는 공개키 증명서를 사용할 수 없게 된 상태에서의 공개키 증명서의 갱신에 대해서는 특별히 언급하고 있지 않다.

또한, 생산 설비 등의 상태에 따라, 통상 사용하는 공개키 증명서에 대해서도, 전술한 비상용의 공개키 증명서의 경우와 같이, 각 장치에 공통적인 공개키 증명서를 설정하지 않을 수 없는 경우도 있다. 그리고, 이러한 경우에는 상기한 비상용의 통신 경로를 이용하는 경우와 마찬가지로, 통상 사용하는 공개키 증명서를, 그 유효 기간 내에 갱신하는 경우라도, 위장을 효과적으로 방지할 수 있도록 할 것이 요구되고 있었다.

본 발명의 목적은, 상기와 같은 문제점을 제거한, 검사 장치, 검사 방법, 통신 시스템, 컴퓨터-실행가능한 프로그램 제품, 및 컴퓨터-판독가능한 기록 매체를 제공하는 것이다.

본 발명의 더 구체적인 목적은, 검사 장치, 검사 방법, 통신 시스템, 컴퓨터-실행가능한 프로그램 제품, 및 컴퓨터-판독가능한 기록 매체로서, 더 구체적으로는, 공개키 암호를 이용하여 인증 처리를 행하기 위한 검사 장치 및 통신 장치 검사 방법과, 검사 대상의 통신 장치를 검사하기 위한 검사 장치를 포함하는 통신 시스템과, 통신 장치를 검사하기 위한 검사 장치로서 컴퓨터를 동작시키는 컴퓨터-실행가능한 컴퓨터 프로그램 제품과, 통신 장치를 검사하기 위한 검사 장치로서 컴퓨터를 기능시키는 프로그램이 기록된 컴퓨터-판독가능한 기록 매체를 제공하되, 안전성이 비교적 낮은 공개키 증명서를 이용하여 통신 장치를 식별해야 하는 경우에 있어서도 위장(spoofing)을 효과적으로 방지할 수 있도록 하는 것이다.

본 발명의 상기 목적은 공개키 암호를 이용하여 인증 처리를 행하는 통신 장치를 검사하기 위한 검사 장치에 의해 달성된다. 이 검사 장치는, 공개키 암호를 이용한 인증 처리를 하지만 그 인증 처리에 사용하는 공개키 증명서는 특정한 통신 상대에게만 건네지는 통신 장치로부터, 상기 통신 장치의 공개키 증명서와 상기 통신 장치의 식별 정보를 수신하는 수신 수단과; 상기 수신 수단이 수신한 식별 정보에 대응하는 공개키 증명서의 내용을 나타내는 정보를, 상기 식별 정보를 바탕으로 상기 통신 장치와는 다른 장소로부터 취득하는 취득 수단과; 상기 취득 수단이 취득한 정보를 참조하여, 수신한 공개키 증명서가 적절한 것인지의 여부에 기초하여 상기 통신 장치를 검사하는 검사 수단을 포함한다.

이러한 검사 장치에 있어서, 상기 검사 수단은, 상기 수신 수단이 수신한 공개키 증명서의 내용과 상기 취득 수단이 취득한 정보가 일치하는지의 여부에 기초하여 상기 공개키 증명서가 적절한 것인지의 여부를 판단하는 수단을 포함할 수 있다.

또한, 본 발명의 상기 목적은 공개키 암호를 이용하여 인증 처리를 행하는 통신 장치를 검사하기 위한 검사 장치에 의해 달성된다. 이 검사 장치는, 공개키 암호를 이용한 인증 처리를 하는 통신 장치로부터, 상기 통신 장치의 개인키와, 상기 통신 장치의 식별 정보를 수신하는 수신 수단과; 상기 수신 수단이 수신한 식별 정보와 대응하는 공개키를, 그 식별 정보를 바탕으로 상기 통신 장치와는 다른 장소로부터 취득하는 취득 수단과; 상기 취득 수단이 취득한 공개키와 상기 수신 수단이 수신한 개인키가 대응하는 것인지의 여부에 기초하여 상기 통신 장치를 검사하는 검사 수단을 포함한다.

이 검사 장치는, 통신 장치의 식별 정보와 그 통신 장치가 상기 인증 처리에 사용하는 공개키와의 대응 관계를 기억하는 수단을 더 포함할 수 있다.

또한, 이 검사 장치에서, 검사 수단은, 상기 취득 수단이 취득한 공개키와 상기 수신 수단이 수신한 개인키 중 한 쪽을 이용하여 주어진 데이터를 암호화하고, 다른 쪽을 이용하여 그 암호화한 데이터를 복호화하여, 그 복호화 결과에 기초하여 검사를 하는 수단을 포함할 수 있다.

또한, 상기 검사 장치는, 상기 통신 장치가 상기 검사 수단에 의한 검사에 합격한 경우에, 상기 통신 장치에, 그 통신 장치의 새로운 공개키 증명서를 송신하는 송신 수단을 더 포함할 수 있다.

상기 송신 수단이 송신하는 공개키 증명서는, 상기 수신 수단이 수신한 상기 통신 장치의 식별 정보를 포함하는 공개키 증명서일 수 있다.

또한, 본 발명의 상기 목적은 통신 장치와 검사 장치를 포함하는 통신 시스템에 의해 달성된다. 여기서, 통신 장치는, 공개키 암호를 이용한 인증 처리를 하지만 그 인증 처리에 사용하는 공개키 증명서는 특정한 통신 상대에게만 건네는 인증 수단과; 통신 장치 자신의 공개키 증명서와 상기 통신 장치 자신의 식별 정보를 검사 장치에 송신하는 수단을 가진다. 상기 검사 장치는, 상기 통신 장치로부터 상기 통신 장치의 공개키 증명서와 그 통신 장치의 식별 정보를 수신하는 수신 수단과; 상기 수신 수단이 수신한 식별 정보와 대응하는 공개키 증명서의 내용을 나타내는 정보를, 상기 식별 정보를 바탕으로 상기 통신 장치와는 다른 장소로부터 취득하는 취득 수단과; 상기 취득 수단이 취득한 정보를 참조하여, 수신한 공개키 증명서가 적절한 것인지의 여부에 기초하여 상기 통신 장치를 검사하는 검사 수단을 포함한다.

이러한 통신 시스템에 있어서, 상기 검사 장치의 검사 수단은, 상기 수신 수단이 수신한 공개키 증명서의 내용과 상기 취득 수단이 취득한 정보가 일치하는지의 여부에 기초하여 상기 공개키 증명서가 적절한 것인지의 여부를 판단하는 수단을 포함할 수 있다.

또한, 본 발명의 상기 목적은 통신 장치와 검사 장치를 포함하는 통신 시스템에 의해 달성된다. 여기서, 통신 장치는, 공개키 암호를 이용한 인증 처리를 하는 인증 수단과; 통신 장치 자신의 개인키와 상기 통신 장치 자신의 식별 정보를 검사 장치에 송신하는 수단을 가진다. 상기 검사 장치는, 상기 통신 장치로부터 상기 통신 장치의 개인키와, 상기 통신 장치의 식별 정보를 수신하는 수신 수단과; 상기 수신 수단이 수신한 식별 정보와 대응하는 공개키를 그 식별 정보를 바탕으로 상기 통신 장치와는 다른 장소로부터 취득하는 취득 수단과; 상기 취득 수단이 취득한 공개키와 상기 수신 수단이 수신한 개인키가 대응하는 것인지의 여부에 기초하여 상기 통신 장치를 검사하는 검사 수단을 포함한다.

이러한 통신 시스템에 있어서, 상기 검사 장치는, 통신 장치의 식별 정보와 그 통신 장치가 상기 인증 처리에 사용하는 공개키와의 대응 관계를 기억하는 수단을 더 포함할 수 있다.

더욱이, 이러한 통신 시스템에서, 상기 검사 장치의 검사 수단은, 상기 취득 수단이 취득한 공개키와 상기 수신 수단이 수신한 개인키 중 한 쪽을 이용하여 주어진 데이터를 암호화하고, 다른 쪽을 이용하여 그 암호화한 데이터를 복호화하여 그 복호화 결과에 기초하여 검사를 하는 수단을 포함한다.

또한, 이러한 통신 시스템에서, 상기 검사 장치는, 상기 통신 장치가 상기 검사 수단에 의한 검사에 합격한 경우, 상기 통신 장치에 그 통신 장치의 새로운 공개키 증명서를 송신하는 송신 수단을 더 포함할 수 있으며, 상기 통신 장치는 그 공개키 증명서를 수신하는 수단을 더 포함한다.

이러한 통신 시스템에서, 상기 검사 장치의 송신 수단이 송신하는 공개키 증명서는, 상기 수신 수단이 수신한 상기 통신 장치의 식별 정보를 포함하는 공개키 증명서일 수 있다.

이러한 통신 시스템에서, 상기 통신 장치에서, 상기 인증 처리에 사용하는 공개키 증명서와 개인키를, 독립적으로 교환 가능한 복수의 메모리 유닛에 분산시켜 기억할 수도 있다.

본 발명의 상기 목적은 공개키 암호를 이용하여 인증 처리를 행하는 통신 장치를 검사하기 위한 검사 방법에 의해 달성된다. 이 검사 방법은, 공개키 암호를 이용한 인증 처리를 하지만 그 인증 처리에 사용하는 공개키 증명서는 특정한 통신 상대에게만 건네지는 통신 장치로부터, 상기 통신 장치의 공개키 증명서와 상기 통신 장치의 식별 정보를 수신하는 단계와; 상기 수신 단계에서 수신한 식별 정보에 대응하는 공개키 증명서의 내용을 나타내는 정보를, 상기 식별 정보를 바탕으로 상기 통신 장치와는 다른 장소로부터 취득하는 취득 단계와; 상기 취득 단계에서 취득한 정보를 참조하여, 수신한 공개키 증명서가 적절한 것인지의 여부에 기초하여 상기 통신 장치를 검사하는 검사 단계를 포함한다.

이러한 검사 방법에 있어서, 상기 검사 단계는, 상기 수신 단계에서 수신한 공개키 증명서의 내용과, 상기 취득 순서에서 취득한 정보가 일치하는지의 여부에 기초하여 상기 공개키 증명서가 적절한 것인지의 여부를 판단하는 단계를 포함할 수 있다.

또한, 본 발명의 상기 목적은 공개키 암호를 이용하여 인증 처리를 행하는 통신 장치를 검사하기 위한 검사 방법에 의해 달성된다. 이 검사 방법은, 공개키 암호를 이용한 인증 처리를 하는 통신 장치로부터, 상기 통신 장치의 개인키와, 상기 통신 장치의 식별 정보를 수신하는 수신 단계와; 상기 수신 단계에서 수신한 식별 정보와 대응하는 공개키를, 상기 통신 장치와는 다른 장소로부터 취득하는 취득 단계와; 상기 취득 단계에서 취득한 공개키와 상기 수신 수단이 수신한 개인키가 동일한 것인지의 여부에 기초하여 상기 통신 장치를 검사하는 검사 단계를 포함한다.

이러한 검사 방법에 있어서, 상기 각 단계들을 실행하는 장치에, 통신 장치의 식별 정보와 그 통신 장치가 상기 인증 처리에 사용하는 공개키와의 대응 관계를 기억시켜 둘 수도 있다.

또한, 상기 검사 단계는, 상기 취득 단계에서 취득한 공개키와 상기 수신 단계에서 수신한 개인키 중 한 쪽을 이용하여 주어진 데이터를 암호화하고, 다른 쪽을 이용하여 그 암호화한 데이터를 복호화하여, 그 복호화 결과에 기초하여 상기 검사를 하는 단계를 포함할 수 있다.

또한, 상기 검사 방법은, 상기 통신 장치가 상기 검사 단계에 있어서의 검사에 합격한 경우에, 상기 통신 장치에, 그 통신 장치의 새로운 공개키 증명서를 송신하는 송신 단계를 더 포함할 수 있다.

더욱이, 상기 송신 단계에서 송신하는 공개키 증명서는, 상기 수신 단계에서 수신한 상기 통신 장치의 식별 정보를 포함하는 공개키 증명서일 수 있다.

본 발명의 상기 목적은, 컴퓨터로 하여금 공개키 암호를 이용하여 인증 처리를 행하도록 하는 컴퓨터-실행가능한 프로그램 제품에 의해 달성된다. 이 컴퓨터-실행가능한 프로그램 제품은, 공개키 암호를 이용한 인증 처리를 하지만 그 인증 처리에 사용하는 공개키 증명서는 특정한 통신 상대에게만 건네지는 통신 장치로부터, 상기 통신 장치의 공개키 증명서와 상기 통신 장치의 식별 정보를 수신하는 수신 단계의 코드와; 상기 수신 단계의 코드에서 수신한 식별 정보에 대응하는 공개키 증명서의 내용을 나타내는 정보를, 상기 식별 정보를 바탕으로 상기 통신 장치와는 다른 장소로부터 취득하는 취득 단계의 코드와; 상기 취득 단계의 코드에서 취득한 정보를 참조하여, 수신한 공개키 증명서가 적절한 것인지의 여부에 기초하여 상기 통신 장치를 검사하는 검사 단계의 코드를 포함한다.

이러한 컴퓨터-실행가능한 프로그램 제품에 있어서, 상기 통신 장치를 검사하는 단계의 코드는, 상기 수신 단계의 코드가 수신한 공개키 증명서의 내용과 상기 취득 단계의 코드가 취득한 정보가 일치하는지의 여부에 기초하여 상기 공개키 증명서가 적절한 것인지의 여부를 판단하는 코드를 포함할 수 있다.

또한, 본 발명의 상기 목적은, 컴퓨터로 하여금 공개키 암호를 이용하여 인증 처리를 행하도록 하는 컴퓨터-실행가능한 프로그램 제품에 의해 달성된다. 이 컴퓨터-실행가능한 프로그램 제품은, 공개키 암호를 이용한 인증 처리를 하는 통신 장치로부터, 상기 통신 장치의 개인키와, 상기 통신 장치의 식별 정보를 수신하는 수신 단계의 코드와; 상기 수신 단계의 코드에서 수신한 식별 정보와 대응하는 공개키를, 상기 통신 장치와는 다른 장소로부터 취득하는 취득 단계의 코드와; 상기 취득 단계의 코드에서 취득한 공개키와 상기 수신 단계의 코드가 수신한 개인키가 동일한 것인지의 여부에 기초하여 상기 통신 장치를 검사하는 검사 단계의 코드를 포함한다.

이러한 컴퓨터-실행가능한 프로그램 제품은, 통신 장치의 식별 정보와 그 통신 장치가 상기 인증 처리에 사용하는 공개키와의 대응 관계를 기억하는 코드를 포함할 수 있다.

또한, 상기 통신 장치를 검사하는 단계의 코드는, 상기 취득 단계의 코드가 취득한 공개키와 상기 수신 단계의 코드가 수신한 개인키 중 한 쪽을 이용하여 주어진 데이터를 암호화하고, 다른 쪽을 이용하여 그 암호화한 데이터를 복호화하여, 그 복호화 결과에 기초하여 검사를 하는 코드를 포함할 수 있다.

또한, 상기 컴퓨터-판독가능한 프로그램 제품은, 상기 통신 장치가 상기 검사 단계의 코드에 의한 검사에 합격한 경우에, 상기 통신 장치에, 그 통신 장치의 새로운 공개키 증명서를 송신하기 위한 코드를 더 포함한다.

더욱이, 상기 공개키 증명서를 송신하기 위한 코드에 의해 설정된 공개키 증명서는, 상기 수신 단계의 코드가 수신한 상기 통신 장치의 식별 정보를 포함하는 공개키 증명서일 수 있다.

또한, 본 발명의 상기 목적은, 컴퓨터로 하여금 공개키 암호를 이용하여 인증 처리를 하도록 하는 프로그램이 기록된 컴퓨터-판독가능한 기록 매체에 의해 달성될 수 있다. 상기 컴퓨터-판독가능한 기록 매체는, 공개키 암호를 이용한 인증 처리를 하는 통신 장치로부터, 상기 통신 장치의 개인키와, 상기 통신 장치의 식별 정보를 수신하는 수신 단계의 코드와; 상기 수신 단계의 코드에서 수신한 식별 정보와 대응하는 공개키를, 상기 통신 장치와는 다른 장소로부터 취득하는 취득 단계의 코드와; 상기 취득 단계의 코드에서 취득한 공개키와 상기 수신 단계의 코드가 수신한 개인키가 동일한 것인지의 여부에 기초하여 상기 통신 장치를 검사하는 검사 단계의 코드를 포함한다.

본 발명의 다른 목적, 특징, 및 이점들은 첨부된 도면과 연계한 이하의 상세한 설명을 통해 보다 명백해질 것이다.

도 1은 2개의 통신 장치가 SSL에 따른 상호 인증을 할 때에 각 장치에 있어서 실행하는 처리의 흐름도를 그 처리에 이용하는 정보와 함께 도시한 도면이다.

도 2a 및 2b는 도 1에 도시한 인증 처리에 있어서 루트 키, 루트 개인키 및 공개키 증명서간의 관계에 관하여 설명하기 위한 도면이다.

도 3은 2개의 통신 장치가 SSL에 따른 한방향 인증을 할 때의 각 장치에 있어서 실행하는 처리를 도시하는, 도 1과 대응하는 도면이다.

도 4는 본 발명의 실시예에 따른 통신 시스템의 구성예를 도시하는 블록도이다.

도 5는 본 발명의 실시예에 따라 도 4에 도시한 관리 장치의 하드웨어 구성을 도시하는 블록도이다.

도 6은 본 발명의 실시예에 따라 도 4에 도시한 관리 장치 및 관리대상 기기 에 관해서, 본 발명의 특징에 관련되는 부분의 기능 구성을 도시하는 기능 블록도이다.

도 7은 본 발명의 실시예에 따라 도 6에 도시한 관리대상 기기의 요구 관리부에 있어서의 커맨드 실행 가부의 판단 기준에 관해서 설명하기 위한 도면이다.

도 8은 본 발명의 실시예에 따라 도 4 및 도 6에 도시한 관리 장치 및 관리대상 기기가 인증 처리에 이용하는 증명서 및 키에 관해서 설명하기 위한 도면이다.

도 9는 본 발명의 실시예에 따라 도 8에 도시한 공개키 증명서의 포맷의 예에 관해서 설명하기 위한 도면이다.

도 10은 본 발명의 실시예에 따라 도 9에 기재한 포맷에 따른 관리대상 기기용 통상 공개키 증명서의 예를 도시하는 도면이다.

도 11은 본 발명의 실시예에 따라 관리대상 기기용 레스큐 공개키 증명서의 예를 도시하는 도면이다.

도 12는 본 발명의 실시예에 따라 도 4에 도시한 통신 시스템에 있어서의 정규 인증 정보와 레스큐 인증 정보를 구별하여 사용하는 것에 관해서 설명하기 위한 도면이다.

도 13은 본 발명의 실시예에 따라 관리 장치가 관리대상 기기에 정규 인증 정보를 설정시킬 때에 송신하는 증명서 등의 구성을 도시한 도면이다.

도 14는 본 발명의 실시예에 따라 도 4에 도시한 통신 시스템에 있어서, 관리대상 기기 중의 인증에 사용할 수 없게 된 정규 인증 정보를 갱신할 때에 각 장 치가 실행하는 처리의 흐름을 도시하는 시퀀스도이다.

도 15는 본 발명의 실시예에 따라 도 4에 도시한 관리 장치의 증명서 기억부에 설치하는 증명서 데이터베이스의 구성예의 일부를 도시한 도면이다.

도 16은 본 발명의 실시예에 따라 도 4에 도시한 관리 장치의 증명서 기억부에 설치하는 증명서 데이터베이스의 구성예의 또 다른 일부를 도시한 도면이다.

도 17은 본 발명의 실시예에 따라 도 14에 도시한 처리를 실행하는 경우의, 관리대상 기기 측의 처리를 도시하는 흐름도이다.

도 18은 본 발명의 실시예에 따라, 관리 장치가, 관리대상 기기와의 통상의 통신에 의해 정규 인증 정보를 갱신하기 위해 발행처의 관리대상 기기를 검사하도록 하는 경우에, 정규 인증 정보를 갱신할 때에 관리대상 기기가 실행하는 처리의 흐름을 도시하는 시퀀스도이다.

도 19는 본 발명의 실시예에 따라, 관리 장치가, 관리대상 기기와의 통상의 통신에 의해 정규 인증 정보를 갱신하기 위해 발행처의 관리대상 기기를 검사하도록 하는 경우에, 정규 인증 정보를 갱신할 때에 관리 장치가 실행하는 처리의 흐름을 도시하는 시퀀스도이다.

도 20은 본 발명의 실시예에 따라, 관리 장치가, 관리대상 기기와의 통상의 통신에 의해 정규 인증 정보를 갱신하기 위해 발행처의 관리대상 기기를 검사하도록 하는 경우에, 정규 인증 정보를 갱신할 때에 관리 장치가 실행하는 처리의 흐름을 도시하는 시퀀스인 도 19의 흐름에 대해 계속 이어지는 처리를 도시하는 흐름도이다.

도 21은 본 발명의 실시예에 따라, 도 19의 단계 S97에 도시한 공개키 증명서를 이용한 검사 처리의 일례를 도시하는 흐름도이다.

도 22는 본 발명의 실시예에 따라, 도 19의 단계 S97에 도시한 공개키 증명서를 이용한 검사 처리의 도 따른 일례를 도시하는 흐름도이다.

도 23은 본 발명의 실시예에 따라, 도 19의 단계 S98에 도시한 개인키를 이용한 검사 처리의 일례를 도시하는 흐름도이다.

도 24는 본 발명의 실시예에 따라, 도 6에 도시한 관리대상 기기의 증명서 기억부 구성의 한 예를 설명하기 위한 도면이다.

도 25는 본 발명의 실시예에 따라, 도 6에 도시한 관리대상 기기의 증명서 기억부 구성의 또 다른 예를 설명하기 위한 도면이다.

도 26은 본 발명의 실시예에 따라, 도 6에 도시한 관리대상 기기의 증명서 기억부 구성의 역시 또 다른 예를 설명하기 위한 도면이다.

도 27은 본 발명의 한 실시예에 따라, 도 4에 도시한 통신 시스템에 있어서 관리대상 기기를 복수 설치한 예를 도시하는 도면이다.

이하, 본 발명의 바람직한 실시의 형태를 도면을 참조하여 설명한다.

이 실시예에 있어서는, 도 3에 도시한 바와 같이, 검사 장치인 관리 장치(30) 및 그 통신 상대가 되는 통신 장치인 관리대상 기기(40)에 의해서 통신 시스템을 구성하고 있다.

그리고, 이 통신 시스템(1000)에 있어서, 관리 장치(30)는, 관리대상 기기 (40)와 통신을 하고자 하는 경우, 공개키 암호와 디지털 증명서(공개키 증명서)를 이용하는 인증 방식인 SSL 프로토콜에 따른 인증 처리에 의해서 관리대상 기기(40)를 정당한 통신 상대로서 인증한 경우에, 관리대상 기기(40)와의 사이에서 통신을 확립시키도록 하고 있다. 그리고, 관리 장치(30)가 송신한 동작 요구(커맨드)에 대하여, 관리대상 기기(40)가 필요한 처리를 하여 응답을 회신함으로써, 클라이언트·서버 시스템으로서 기능한다.

반대로, 관리대상 기기(40)가 관리 장치(30)와 통신을 하고자 하는 경우에도, 마찬가지로 SSL에 따른 인증 처리에 의해서 관리 장치(30)를 정당한 통신 상대로서 인증한 경우에, 관리 장치(30)와의 사이에서 통신을 확립시키도록 하고 있다. 그리고, 관리대상 기기(40)가 송신한 동작 요구(커맨드)에 대하여, 관리 장치(30)가 필요한 처리를 하여 응답을 회신함으로써, 클라이언트·서버 시스템으로서 기능한다.

어느 쪽의 경우도, 통신을 요구하는 쪽이 클라이언트, 요구를 받는 쪽이 서버로서 기능하는 것으로 한다.

한편, 이 통신 시스템(1000)에 있어서, 관리 장치(30)는 관리대상 기기(40)를 관리하는 기능 외에, 관리대상 기기(40)에 대하여, 통상 사용하는 공개키 증명서를 이용하여 상기와 같은 SSL에 의한 인증을 할 수 없게 된 상태에서 통상의 인증을 하기 위한 공개키 증명서를 재발행하는 기능과, 그 재발행을 하는 경우에 있어서, 그 재발행처의 관리대상 기기(40)를 검사하여 재발행을 해도 좋은지의 여부를 판단하는 기능도 갖는다.

도 4에 있어서, 관리대상 기기(40)는 하나밖에 나타내고 있지 않지만, 도 23에 도시한 바와 같이 관리대상 기기(40)를 복수 설치하는 것도 가능하다. 또한, 관리대상 기기(40)가 한 종류일 필요도 없다. 다만, 관리 장치(30)는 하나의 통신 시스템(1000)에 대해서 하나이다.

이러한 통신 시스템(1000)에 있어서, 전술한 관리 장치(30)와 관리대상 기기(40) 사이의 통신은 RPC(remote procedure call)에 의해, 서로의 실장하는 애플리케이션 프로그램의 메소드에 대한 처리의 의뢰인 「요구」를 송신하고, 이 의뢰된 처리의 결과인 「응답」을 취득할 수 있게 되어 있다.

이 RPC를 실현하기 위해서는, SOAP(Simple Object Access Protocol), HTTP(Hyper Text Transfer Protocol), FTP(File Transfer Protocol), COM(Component Object Model), CORBA(Common Object Request Broker Architecture)등의 이미 알려진 프로토콜(통신 규격), 기술, 사양 등을 이용할 수 있다.

이어서, 도 4에 도시한 관리 장치(30) 및 관리대상 기기(40)의 구성과 기능에 대해 보다 상세히 설명한다.

도 1에 도시한 관리 장치(30) 및 관리대상 기기(40)는 장치의 원격 관리, 전자 상거래 등의 목적에 따라서 여러 가지 구성을 채용할 수 있다. 예컨대, 원격 관리의 경우에는 프린터, FAX 장치, 복사기, 스캐너, 디지털 복합기 등의 화상 처리 장치를 비롯하여, 네트워크 가전, 자판기, 의료 기기, 전원 장치, 공조 시스템, 가스·수도·전기 등의 계량 시스템, 자동차, 항공기 등의 전자 장치를 피관리 장치인 관리대상 기기(40)로 하고, 이들 피관리 장치로부터 정보를 수집하거나, 커맨드 를 보내어 동작시키거나 하기 위한 관리 장치를 관리 장치(30)로 하는 것을 생각할 수 있다.

도 5에 본 발명의 실시예에 따른 관리 장치(30)의 하드웨어 구성예를 도시한다. 도 5에 도시한 바와 같이, 관리 장치(30)는 예컨대 CPU(11), ROM(12), RAM(13), HDD(14), 통신 인터페이스(I/F)(15)를 설치하고, 이들을 시스템 버스(16)에 의해서 접속하여 구성할 수 있다. 그리고, CPU(11)가 ROM(12)이나 HDD(14)에 기억하고 있는 각종 제어 프로그램을 실행함으로써 이 관리 장치(30)의 동작을 제어하여, 통신 상대의 인증, 관리대상 기기(40)와의 통신, 관리대상 기기(40)의 관리나 검사, 공개키 증명서의 발행 등의 기능을 실현시키고 있다.

물론, 관리 장치(30)로서 적절하게 공지된 컴퓨터를 이용하거나, 필요에 따라서 다른 하드웨어를 부가하거나 하여도 좋다.

또한, 관리대상 기기(40)도, 적어도 각각 CPU, ROM, RAM, 네트워크를 통해 외부 장치와 통신하기 위한 통신 I/F 및 인증 처리에 필요한 정보를 기억하는 기억 수단을 갖추어, CPU가 ROM 등에 기억한 사전설정된 제어 프로그램을 실행함으로써, 장치에 본 발명에 따른 각 기능을 실현시킬 수 있는 것으로 한다.

이 관리 장치(30)와 관리대상 기기(40) 사이의 통신에는 유선, 무선을 막론하고, 네트워크를 구축할 수 있는 각종 통신 회선(통신 경로)을 채용할 수 있다.

도 6에, 관리 장치(30) 및 관리대상 기기(40)의, 이 실시예의 특징에 관련된 부분의 기능 구성에 관한 기능 블록도를 도시한다. 한편, 도 6 중의 화살표는 후술하는 바와 같이 관리대상 기기(40)가 통상의 공개키 증명서를 이용한 인증을 받을 수 없었던 상태에서 관리대상 기기(40)에 그 통상의 공개키 증명서를 재발행하는 경우의 데이터의 흐름을 도시하는 것이다.

우선, 관리 장치(30)는 HTTPS(Hypertext Transfer Protocol Security) 클라이언트 기능부(31), HTTPS 서버 기능부(32), 인증 처리부(33), 증명서 기억부(34), 증명서 검사부(35), 증명서 발행부(36), 커맨드 발행부(37), 요구 관리부(38), 커맨드 처리부(39)를 갖추고 있다.

HTTPS 클라이언트 기능부(31)는 SSL에 따른 인증이나 암호화의 처리를 포함하는 HTTPS 프로토콜을 이용하여, 관리대상 기기(40) 등의 HTTPS 서버의 기능을 갖는 장치에 대하여 통신을 요구하는 기능을 갖는다.

한편, HTTPS 서버 기능부(32)는 HTTPS 클라이언트의 기능을 갖는 장치로부터의 HTTPS 프로토콜을 이용한 통신 요구를 접수하는 기능을 갖는다.

따라서, 이들 HTTPS 클라이언트 기능부(31)와 HTTPS 서버 기능부(32)에서, 통신 상대에 대하여 커맨드나 데이터를 송신하여 그에 따른 동작을 실행시키는 기능과, 통신 상대로부터 요구나 데이터를 수신하고 그에 따른 동작을 장치의 각부에 실행시켜, 그 결과를 응답으로서 요구원에 회신하는 기능을 실현하고 있다. 이 경우에 있어서, 통신을 요구한 측이 커맨드를 송신하는 경우도 있고, 통신 요구를 접수한 측이 커맨드를 송신하는 경우도 있다. 응답에 대해서도 마찬가지이다.

인증 처리부(33)는 HTTPS 클라이언트 기능부(31)나 HTTPS 서버 기능부(32)가 통신 상대를 인증할 때에, 통신 상대로부터 수신한 공개키 증명서나, 증명서 기억부(34)에 기억하고 있는 각종 증명서, 개인키 등을 이용하여 인증 처리를 하는 인 증 수단의 기능을 갖는다. 또한, 통신 상대에게 인증을 요구하기 위해서, 증명서 기억부(34)에 기억하고 있는 공개키 증명서를 HTTPS 클라이언트 기능부(31)나 HTTPS 서버 기능부(32)를 통해 통신 상대에게 송신하는 기능도 갖는다.

증명서 기억부(34)는 공개키 증명서나 개인키, 루트 키 증명서 등의 인증 정보를 기억하여, 인증 처리부(33)에 있어서의 인증 처리에 사용하게 하는 기능을 갖는다. 그리고, 증명서 기억부(34)가 기억하고 있는 인증 정보에는, 상세한 것은 후술하지만, 통상의 통신시의 인증 처리에 사용하는 정규 인증 정보와, 정규 인증 정보에 의한 인증을 할 수 없게 된 경우의 복구에 사용하는 비상용의 레스큐 인증 정보가 있다. 또한, 증명서 기억부(34)는 증명서 발행부(36)가 발행한 공개키 증명서 및 그 발행처나 발행일에 관한 정보를 데이터베이스로서 기억해 두는 기능도 갖는다.

증명서 검사부(35)는 인증 처리부(33)가 레스큐 인증 정보에 의해 관리대상 기기(40)와의 사이에서 인증 처리를 한 경우에, 그 관리대상 기기(40)로부터 수신하는 기기 번호나 증명서 등의 정보를 바탕으로, 그 관리대상 기기(40)에 대하여 갱신용의 공개키 증명서나 개인키를 발행하여도 좋은지를 검사하는 기능을 갖는다. 증명서 발행부(36)는 증명서 검사부(35)가 검사하여 발행하여도 좋다고 판단한 경우에, 갱신용의 공개키 증명서나 개인키를 발행하여, 이들을 관리대상 기기(40)에 송신하는 기능을 갖는다. 한편 공개키 증명서의 발행에 대해서는, 관리대상 기기(40)가 작성하여 송신하여 온 공개키에 디지털 서명을 붙여 반송하도록 하는 것도 생각할 수 있다.

커맨드 발행부(37)는 관리대상 기기(40)에 대하여 여러 가지 커맨드를 발행하여 관리대상 기기(40)에 그 커맨드에 따른 동작을 실행시키는 기능을 갖는다. 관리대상 기기(40)에 실행시키는 동작으로서는, 관리대상 기기(40)의 동작 내용이나 설정 상태에 관한 정보의 송신, 관리 장치(30)로부터 송신한 갱신용의 공개키 증명서를 비롯한 정보의 기억이나 그것에 따른 설정 변경 등을 생각할 수 있다. 그리고, 커맨드 발행부(37)는 관리대상 기기(40)로부터 취득한 정보에 따라서 관리대상 기기(40)에 여러 가지 동작을 실행시킴으로써, 관리대상 기기(40)를 관리하는 기능도 갖는다.

요구 관리부(38)는 관리 장치로부터 수신한 커맨드에 관해서, 그 커맨드에 기초한 동작의 실행 가부를 판단하는 기능을 갖는다. 그리고, 실행을 허가하는 경우에, 그 커맨드에 기초한 동작을 실행하는 기능부에 대하여 커맨드를 전하는 기능도 갖는다. 한편, 커맨드에 기초한 동작을 실행하는 기능부는 실제로는 복수의 독립된 모듈로서 구성하는 것을 생각할 수 있지만, 도 3에서는 커맨드 처리부(39)로서 일괄적으로 나타내고 있다. 그리고, 이 커맨드 처리부(39)가 실행하는 동작으로서는, 예컨대 관리대상 기기(40)로부터의 이상 발생 통지에 대한 대응이나, 관리대상 기기(40)로부터의 요구에 따라서 관리 장치(30)가 기억하고 있는 데이터를 송신하는 동작 등을 들 수 있다.

이상의 각 부의 기능은 관리 장치(30)의 CPU가 사전설정된 제어 프로그램을 실행하여 관리 장치(30)의 각 부의 동작을 제어함으로써 실현된다.

이어서, 관리대상 기기(40)에는, HTTPS 클라이언트 기능부(41), HTTPS 서버 기능부(42), 인증 처리부(43), 콜 통지부(44), 정기 통지부(45), 증명서 기억부(46), 증명서 통지부(47), 요구 관리부(48), 증명서 설정부(49), 커맨드 처리부(50)를 갖추고 있다.

HTTPS 클라이언트 기능부(41)는 관리 장치(30)의 HTTPS 클라이언트 기능부(31)와 마찬가지로, HTTPS 프로토콜을 이용하여 관리 장치(30) 등의 HTTPS 서버의 기능을 갖는 장치에 대하여 통신을 요구하는 동시에, 커맨드나 그것에 대한 응답을 송수신하는 기능을 갖는다.

HTTPS 서버 기능부(42)도, 관리 장치(30)의 HTTPS 서버 기능부(32)와 마찬가지로, HTTPS 클라이언트의 기능을 갖는 장치로부터의 통신 요구를 접수하는 동시에, 커맨드나 그것에 대한 응답을 송수신하는 기능을 갖는다.

인증 처리부(43)의 기능도, 관리 장치(30)의 인증 처리부(33)와 마찬가지인데, 인증 처리에 사용하는 증명서 등은 증명서 기억부(46)에 기억하고 있는 것이다.

콜 통지부(44)는 이상을 검지하거나 사용자에 의한 지시가 있거나 한 경우에 관리 장치(30)에 대하여 그 취지를 통지하는 콜을 실행하는 기능을 갖는다.

정기 통지부(45)는 관리대상 기기(40)에서 관리 장치(30)로의 정기적인 통지를 하는 기능을 갖는다. 그 통지의 내용으로서는, 예컨대 화상 형성 장치라면 화상 형성 매수 카운터의 카운트치, 계량 시스템이라면 그 계량치 등을 생각할 수 있다.

증명서 기억부(46)는 관리 장치(30)의 증명서 기억부(34)와 마찬가지로 각종 증명서나 개인키 등의 인증 정보를 기억하여, 인증 처리부(43)에 있어서의 인증 처 리에 사용하게 하는 증명서 기억 수단의 기능을 갖는다. 다만, 기억하고 있는 증명서 등은 후술하는 바와 같이 증명서 기억부(34)와는 다르다.

정규 인증 정보에 의한 인증이 받아지지 않게 되어, 레스큐 인증 정보에 의해 관리 장치(30)에 인증을 받은 경우 등, 관리 장치(30)에 정규 인증 정보를 이용한 검사를 받을 필요가 있는 경우에, 증명서 통지부(47)는, 관리 장치(30)에, 관리대상 기기(40)의 기기 번호와 함께 그때까지 사용하고 있었던 정규 인증 정보를 송신하여, 관리 장치(30)에 있어서의 관리대상 기기(40)의 검사에 사용하게 하는 기능을 갖는다.

요구 관리부(48)는 관리 장치(30)로부터 수신한 커맨드에 관해서, 그 커맨드에 기초한 동작의 실행 가부를 판단하는 기능을 갖는다. 그리고, 실행을 허가하는 경우에, 그 커맨드에 기초한 동작을 실행하는 증명서 설정부(49) 및 커맨드 처리부(50)와 같은 기능부에 대하여 커맨드를 전하는 기능도 갖는다.

도 7에 이 실행 가부의 판단 기준을 도시하는데, 그 판단 기준은 커맨드의 종류 및 인증 처리부(43)에 있어서 인증 처리에 사용한 인증 정보의 종류이다. 요구 관리부(48)는 도 7에 도시한 바와 같이, 정규 인증 정보에 의한 인증을 한 경우에는 모든 동작을 허가하지만, 레스큐 인증 정보에 의한 인증을 한 경우에는 증명서(개인키도 포함함)의 설정 동작만을 허가하도록 하고 있다. 한편, 여기서는 설정(갱신도 포함함)하는 증명서는 정규 인증 정보를 구성하는 증명서만으로 하고, 레스큐 인증 정보를 구성하는 증명서는 설정하지 않는 것으로 한다. 따라서, 레스큐 인증 정보는 관리대상 기기(40)에 새로운 정규 인증 정보를 기억시키는 경우에만 사용하는 인증 정보로 된다.

증명서 설정부(49)는 관리 장치(30)로부터 수신한 커맨드에 따라서 갱신용의 공개키 증명서 등을, 인증 처리에 사용하는 것으로서 증명서 기억부(46)에 설정하여, 공개키 증명서 등을 갱신하는 기능을 갖는다.

커맨드 처리부(50)는 관리 장치(30)로부터 수신한 커맨드에 따른 동작을 실행하는 기능을 갖는다. 이 동작으로서는, 예컨대 관리대상 기기(40)가 기억하고 있는 데이터의 송신이나, 필요에 따라서 도시하지 않는 엔진부의 동작을 제어하는 것을 들 수 있다. 또, 커맨드에 기초한 동작을 실행하는 기능부는, 관리 장치(30)의 커맨드 처리부(39)의 경우와 마찬가지로, 실제로는 복수의 독립된 모듈로서 구성하는 것을 생각할 수 있다. 그리고, 상기한 증명서 설정부(49)는 이러한 모듈의 하나라고 생각할 수 있다.

그리고, 이들 각 부의 기능은 관리대상 기기(40)의 CPU가 사전설정된 제어 프로그램을 실행하여 관리대상 기기(40)의 각 부의 동작을 제어함으로써 실현될 수 있다.

그 다음, 도 8a 및 8b는, 본 발명의 실시예에 따른 관리 장치(30) 및 관리대상 기기(40)에 의한 인증 처리에 사용되는 증명서와 키 유형을 도시하는 도면이다. 도 8a에 관리대상 기기(40)의 증명서 기억부(46)에 기억하고 있는 증명서 및 키의 종류를 나타내고, 도 8b에 관리 장치(30)의 증명서 기억부(34)에 기억하고 있는 증명서 및 키의 종류를 나타내고 있다. 도 8a 및 8b에서는, 각 장치가 통신 상대와의 사이의 인증 처리에 사용하는 증명서 및 키만을 나타내고 있다.

도 8a에서, 관리대상 기기(40)는 주로 정규 인증 정보(71)와 레스큐 인증 정보(73)를 인증 정보(70)에 기억한다. 또한, 또한 정규 인증 정보(71)는 관리대상 기기(40) 자신에 관한 인증 정보(711)와, 통신 상대에 관한 인증 정보(712)를 포함한다. 또한, 인증 정보(711)는 (관리대상 기기(40) 용의) 통상 공개키 증명서(711a)와 관리대상 기기(40) 자신에 관한 통상 개인키(711b)를 포함한다. 또한, 인증 정보(712)는 관리 장치(30) 인증용 통상 루트 키 증명서(712a)를 포함한다. 유사하게, 레스큐 인증 정보(73)는 관리대상 기기(40) 자신에 관한 인증 정보(731)와, 통신 상대에 관한 인증 정보(732)를 포함한다. 또한, 인증 정보(731)는 관리대상 기기(40) 자신에 관한 레스큐 공개키 증명서(731a)와 레스큐 개인키(731b)를 포함한다. 또한, 인증 정보(732)는 관리 장치(30)에 대한 레스큐 루트 키 증명서(732a)를 포함한다.

도 8b에서, 관리 장치(30)는 주로 정규 인증 정보(81)와 레스큐 인증 정보(83)를 인증 정보(80)에 기억한다. 게다가, 정규 인증 정보(81)는 관리 장치(30) 자신에 관한 인증 정보(811)와, 통신 상대에 관한 인증 정보(812)를 포함한다. 또한, 인증 정보(811)는 (관리 장치(30)용의) 정규 공개키 증명서(811a)와 관리 장치(30) 자신에 관한 정규 개인키(811b)를 포함한다. 또한, 인증 정보(812)는 관리대상 기기(40) 인증용 통상 루트 키 증명서(812a)를 포함한다. 유사하게, 레스큐 인증 정보(83)는 관리 장치(30) 자신에 관한 인증 정보(831)와 통신 상대에 관한 인증 정보(832)를 포함한다. 또한, 인증 정보(831)는 관리 장치(30) 자신에 관한 레스큐 공개키 증명서(831a)와 레스큐 개인키(831b)를 포함한다. 또한, 인증 정보 (832)는 관리대상 기기(40) 용의 레스큐 루트 키 증명서(832a)를 포함한다.

상술한 바와 같이, 정규 인증 정보(71 및 81)와 레스큐 인증 정보(73 및 83)는, 각각 통상 공개키 증명서(711a 및 811a)와, 레스큐 공개키 증명서(731a 및 831a)와, 통상 개인키(711b 및 811b)와, 통상 루트 키 증명서(712a 및 812a)와, 레스큐 루트 키 증명서(732a 및 832a)에 의해 형성된다. 또한, 정규 인증 정보(71 및 81)는 통상의 통신에서 인증 처리를 위해 사용되는 인증 정보이다. 레스큐 인증 정보(73 및 83)는, 정규 인증 정보를 사용하여 인증을 할수 없는 경우에 복구 절차에서 비사용으로 사용되는 인증 정보이다.

관리 장치(30) 및 관리대상 기기(40)의 각각은, 통상의 통신 중에 그 인증 정보를 사용하여 통신 상대와 SSL에 따라, 도 1에 도시된 절차에 의해 상호 인증을 하거나, 도 3에 도시된 절차에 의해 1-방향 인증을 한다.

여기서, 공개키 증명서의 포맷은, 예컨대 도 9에 도시한 것을 이용할 수 있으며, 공개키 그 자체 외에, 증명서의 발행자나 유효 기한 및 시리얼 번호, 증명되는 대상(증명서의 발행처의 장치 또는 이용자) 등의 정보가 기재되어 있다. 이러한 공개키 증명서는, 구체적으로는, 예컨대 X.509라 불리는 포맷에 따라서 작성할 수 있다.

도 10에, 상기한 X.509 포맷에 따라서 작성된 관리대상 기기용 통상 공개키 증명서의 예를 도시한다.

이 예에서는, A가 공개키 증명서의 시리얼 번호를 나타낸다. 또한, B가 공개키 증명서를 발행한(공개키에 디지털 서명을 붙인) 관리 장치(30)의 식별 정보를, D가 증명서의 발행처인 관리대상 기기(40)의 식별 정보를 각각 나타낸다. 이들은 각각 소재지, 명칭, 기기 번호 또는 코드 등의 정보를 포함한다. 다만, 발행처의 장치에 대해서, 기기 번호와 같이 개개의 장치를 식별할 수 있는 식별 정보를 기재하는 것은 필수적이지는 않다. 또한, C가 유효 기간을 나타내고, 그 개시 일시와 종료 일시에 따라 유효 기간을 지정하고 있다. E가 관리대상 기기용 통상 공개키의 본체이다.

또한, 관리대상 기기(30)용 통상 개인키는, 상기한 관리대상 기기(40)용 통상 공개키와 대응하는 개인키, 관리대상 기기(40) 인증용 통상 루트 키 증명서는, 관리대상 기기 인증용 통상 루트 키에 자신과 대응하는 루트 개인키를 이용하여 스스로 정당성을 확인할 수 있는 디지털 서명을 붙인 디지털 증명서이다.

한편, 관리대상 기기(40)를 복수 설치한 경우라도, 각 장치의 관리대상 기기(40)용 통상 공개키에 붙이는 서명은 동일한 루트 개인키를 이용하여 붙이고, 정당성 확인에 필요한 루트 키 증명서는 공통으로 한다. 그러나, 관리대상 기기(40)용 통상 공개키 증명서에 포함되는 공개키나 이것과 대응하는 개인키는 장치마다 다르다.

관리 장치(30)용 통상 공개키 증명서와 관리 장치(30)용 통상 개인키와 관리 장치(30) 인증용 통상 루트 키 증명서도 유사한 관계이다.

예컨대, 관리 장치(30)와 관리대상 기기(40)가 상호 인증을 하는 경우에는, 관리대상 기기(40)로부터의 통신 요구에 따라서, 관리 장치(30)는 관리 장치용 통상 개인키를 이용하여 암호화한 제1 난수를 관리 장치용 통상 공개키 증명서와 함 께 관리대상 기기(40)에 송신한다. 관리대상 기기(40) 측에서는 관리 장치 인증용 통상 루트 키 증명서를 이용하여 우선 이 관리 장치용 통상 공개키 증명서의 정당성(손상이나 위조를 받고 있지 않음)을 확인하여, 이것이 확인된 경우에 여기에 포함되는 공개키로 제1 난수를 복호화한다. 이 복호화가 성공한 경우에, 관리대상 기기(40)는 통신 상대의 관리 장치(30)가 확실히 관리 장치용 통상 공개키 증명서의 발행처라고 인식할 수 있으며, 그 증명서에 포함되는 식별 정보로부터 장치를 특정할 수 있다. 따라서, 관리대상 기기(40)가, 통신 상대로서 특정한 장치가 잘 어울리는지의 여부를 검사하고, 이에 따라 인증의 성공과 실패를 결정할 수 있다.

또한, 관리 장치(30) 측에서도, 관리대상 기기(40) 측에서 인증이 성공한 경우에 송신되어 오는 관리대상 기기용 통상 공개키 증명서 및 관리대상 기기용 통상 개인키로 암호화된 난수를 수신하여, 기억하고 있는 관리대상 기기 인증용 통상 루트 키 증명서를 이용하여 동일한 인증을 할 수 있다.

한편, 이 절차는 관리대상 기기(40)가 HTTPS 클라이언트 기능부(41)에 의해서 관리 장치(30)의 HTTPS 서버 기능부(32)에 대하여 통신을 요구하는 경우의 처리이며, 관리 장치(30)가 HTTPS 클라이언트 기능부(31)에 의해서 관리대상 기기(40)의 HTTPS 서버 기능부(42)에 대하여 통신을 요구하는 경우에는, 사용하는 증명서나 키는 동일하지만, 관리 장치(30)와 관리대상 기기(40)의 처리가 반대가 된다.

여기까지의 설명으로부터 분명한 바와 같이, 각 장치가 통신 상대에 대하여 통상 공개키 증명서를 송신한 경우라도, 증명서가 파손되어 있거나, 증명서의 유효 기한이 끊겨 있거나 한 경우에는 인증을 할 수 없다. 그리고, 이러한 사태는, 인증 정보의 갱신 처리 중에 전원이 끊겨 갱신이 실패하거나, 장치의 전원이 들어가지 않는 채로 방치되어 증명서의 유효 기한 내에 갱신을 할 수 없거나 한 경우에는 충분히 발생할 수 있다.

여기서, 각 장치가 통상 공개키 증명서를 이용한 인증밖에 할 수 없다고 하면, 통상 공개키 증명서가 파손되거나 유효 기간이 지나가 버리거나 하고 있는 상태에서는, 새로운 통상 공개키 증명서나 통상 개인키 및 통상 루트 키 증명서를 네트워크를 통해 안전하게 대상 장치에 송신하는 방법은 없게 된다. 그러나, 이 통신 시스템을 구성하는 각 장치는 이러한 사태에 대처하기 위해서 레스큐 인증 정보를 기억하고 있어, 통신 상대를 다른 2종류의 디지털 증명서를 이용하여 인증할 수 있도록 하고 있다. 그리고, 레스큐 인증 정보를 이용함으로써, 관리 장치(30)로부터 관리대상 기기(40)에 네트워크를 통해 새로운 통상 공개키 증명서 등을 안전하게 송신할 수 있도록 하고 있다.

이 레스큐 인증 정보는, 정규 인증 정보와 대강 동일한 구성으로 되어 있으며, 예컨대 관리대상 기기(40)용 레스큐 공개키 증명서는, 도시하지 않는 레스큐 CA가 작성한 레스큐 공개키에, 관리대상 기기(40) 인증용 레스큐 루트 키를 이용하여 정당성을 확인할 수 있는 디지털 서명을 붙인 디지털 증명서이다. 또한, 관리대상 기기(40)용 레스큐 개인키는 그 레스큐 공개키와 대응하는 개인키, 관리대상 기기(40) 인증용 레스큐 루트 키 증명서는 관리대상 기기 인증용 레스큐 루트 키에 자신을 이용하여 정당성을 확인할 수 있는 디지털 서명을 붙인 디지털 증명서이다.

그리고, 이러한 레스큐 인증 정보로서는, 예컨대, 레스큐 공개키 증명서가, 장치의 식별 정보가 첨부되어 있지 않은 디지털 증명서를 사용하는 것을 생각할 수 있다.

이 경우, 동일한 계위(level)의 장치(도 4에 도시한 예에서는 관리 장치 및 관리대상 기기의 계위가 존재하는 것으로 함)에는 전부 동일한 레스큐 공개키 증명서를 기억시키도록 할 수 있다. 동일한 계위의 각 장치를 개별적으로 구별할 필요가 없기 때문에, 증명서에 포함되는 레스큐 공개키 및 이것과 대응하는 레스큐 개인키도 포함하여, 완전히 공통의 것이라도 좋기 때문이다. 또한, 통신 상대의 레스큐 공개키 증명서가 전부 같으므로, 루트 키 증명서는, 어떤 계위의 장치의 통신 상대가 되는 모든 장치에 대해서 공통으로 된다. 즉, 도 27에 도시한 바와 같이, 관리대상 기기를 복수 설치한 경우라도, 모든 관리대상 기기에 동일한 레스큐 인증 정보를 기억시키게 된다.

이것은 관리 장치(30)의 레스큐 인증 정보에 대해서도 마찬가지이다.

또한, 이러한 레스큐 공개키 증명서도, 통상 공개키 증명서와 같은 식의 포맷으로 작성할 수 있다. 예컨대 도 11에 도시한 바와 같이 형성할 수 있다. 이 경우에 있어서, 예컨대, 부호 G로 나타내는 바와 같이 발행처 장치의 기기 번호(CN)로서 0을 기재하여 공통 증명서임을 나타내는 것을 생각할 수 있다. 또한, 발행원 CA의 정보로서, 부호 F로 나타내는 바와 같이 레스큐 CA의 식별 정보를 기재하고 있다.

이러한 레스큐 인증 정보는, 동일한 계위의 장치에 대해서 전부 공통이라고 하는 특성 때문에, 장치의 제조시에 그 기종에 따라서 정해지는 계위에 따른 것을 기억시켜 버릴 수 있다. 즉, 장치의 식별 정보를 붙인 정보가 아니기 때문에, 검사 공정을 종료하고 식별 번호를 붙인 각 장치에 대하여 각각 개별 증명서를 준비하여 기억시킬 필요는 없으며, 다수의 장치에 대하여 단순 작업에 의해서 기억시킬 수 있다. 예컨대, 제어 프로그램의 마스터에 레스큐 인증 정보를 포함해 두고, 제어 프로그램을 장치에 복사할 때에 레스큐 인증 정보도 함께 기억시키는 것 등이다.

그리고, 그 후 레스큐 인증 정보를 갱신하지 않도록 하면, 상기한 바와 같이 정규 인증 정보의 갱신을 할 수 없거나 파손되어 버리거나 하여 통상 공개키 증명서에 의한 인증을 할 수 없게 된 경우라도, 레스큐 인증 정보에 포함되는 레스큐 공개키 증명서를 이용한 인증이 가능한 상태를 유지할 수 있다.

또한, 레스큐 공개키 증명서나 레스큐 루트 키 증명서를 갱신하지 않도록 하는 것을 생각하면, 그 유효 기간을 길게 하여, 실질적으로 발행처 장치의 사용 중에 유효 기한이 오지 않도록 설정하는 것이 바람직하다. 예컨대, 도 11에 도시한 예에서는 유효 기간을 50년으로 설정하고 있다.

여기서, 장치의 식별 정보를 붙이지 않는 레스큐 공개키 증명서를 이용하는 경우에는, 그 증명서를 이용한 인증을 한 경우라도, 통신 상대의 장치를 구체적으로 특정할 수는 없다. 그러나, 통신 상대에 대해서 어느 정도의 정보는 얻을 수 있다.

즉, 예컨대 어떤 벤더가 자사 제품 중 관리대상 기기(40)에 해당하는 장치 전부에 관리대상 기기용의 레스큐 인증 정보(관리대상 기기용 레스큐 공개키 증명서, 관리대상 기기용 레스큐 개인키 및 관리 장치 인증용 레스큐 루트 키 증명서) 를 기억시키고, 그 통신 상대가 되는 관리 장치(30)에 해당하는 장치를 전부 관리 장치용의 레스큐 인증 정보(관리 장치용 레스큐 공개키 증명서, 관리 장치용 레스큐 개인키 및 관리대상 기기 인증용 레스큐 루트 키 증명서)를 기억시켜 놓으면, 관리대상 기기(40)는, 자신이 기억하고 있는 관리 장치 인증용 레스큐 루트 키 증명서로 정당성을 확인할 수 있는 공개키 증명서를 송신하여 오는 상대가 동일한 벤더의 관리 장치(30)임을 인식할 수 있고, 반대로 관리 장치(30)도 자신이 기억하고 있는 관리대상 기기 인증용 레스큐 루트 키 증명서로 정당성을 확인할 수 있는 공개키 증명서를 송신하여 오는 상대는 동일한 벤더의 관리대상 기기(40)임을 인식할 수 있다.

그리고, 이러한 인증이 성공하면, 상술한 바와 같이 통신 상대와의 사이에서 공통 키를 공유하여 공통 키 암호를 이용한 안전한 통신 경로를 설치할 수 있기 때문에, 그 후 기기 번호 정보 등을 교환하여 통신 상대를 특정하는 것도 가능하다.

따라서, 통상 공개키 증명서에 기재된 식별 정보를 사용하지 않더라도, 통신 상대를 특정하는 것은 일단 가능하다.

한편, 도 8에 도시한 인증 정보에 있어서, 통상 루트 키 증명서는 인증 대상에 상관없이 같은 것을 이용하도록 하더라도 좋다(관리 장치 인증용 통상 루트 키 증명서와 관리대상 기기 인증용 통상 루트 키 증명서가 같은 것이라도 좋음). 이것은 통상 증명서에는 장치의 식별 정보가 첨부되어 있기 때문에, 루트 키 증명서를 이용하여 그 정당성을 확인할 수 있으면, 다음은 그 식별 정보를 참조하여 장치의 기종이나 계위를 특정할 수 있기 때문이다.

그러나, 장치에 식별 정보를 붙이지 않는 레스큐 인증 정보를 공개키 증명서에 채용하는 경우에는, 공개키 증명서에 장치의 식별 정보가 첨부되어 있지 않기 때문에, 특정한 루트 키 증명서로 정당성을 확인할 수 있는지의 여부에 따라서 장치 종류의 구별을 행하게 된다. 따라서, 이 경우의 레스큐 루트 키 증명서는 인증 대상의 계위마다 다를 필요가 있다.

그런데, SSL 프로토콜에 따른 인증 처리를 하는 경우에는, 서버는, 클라이언트로부터 통신 요구가 있었던 시점에서는 클라이언트의 상태를 알 수 없기 때문에, 필연적으로, 특정한 URL(Uniform Resource Locator)에 액세스된 경우에는 항상 동일한 공개키 증명서를 회신하게 된다. 따라서, 기본적으로는, 하나의 서버가 공개키 증명서를 복수 갖고서, 통신 상대가 인증에 사용하고자 하는 공개키 증명서의 종류에 맞춰 적당한 것을 선택하여 송신한다고 하는 구성을 취할 수는 없다. 그러나, 도 4에 도시한 관리대상 기기(40) 및 관리 장치(30)에서는, 특수한 구성을 취함으로써, 통상 공개키 증명서와 레스큐 공개키 증명서를 경우에 따라서 구별지어 사용할 수 있도록 하고 있다.

그 다음, 이 구별지어 사용하는 것을 위한 구성을, 도 12를 이용하여 설명한다.

상술한 바와 같이, 서버는 기본적으로는 통신을 요구하여 오는 클라이언트에 대하여 특정한 공개키 증명서밖에 회신할 수 없다. 그러나, 통신 요구에 관련한 URL이 다른 경우에는 URL마다 다른 공개키 증명서를 회신하는 것도 가능하다.

따라서 여기서는, 도 12에 도시한 바와 같이, 관리 장치(30) 및 관리대상 기 기(40)에 각각, 통상 공개키 증명서에 의한 인증을 하는 통상 URL과, 레스큐 공개키 증명서에 의한 인증을 하는 레스큐 URL을 마련하여, 통신을 요구하는 쪽(클라이언트로서 기능하는 쪽)이, 요구하는 인증의 종류에 따라서 어느 한 URL을 선택적으로 지정하여 통신 요구를 보내도록 하고 있다.

관리 장치(30)와 관리대상 기기(40) 사이의 통신 프로토콜에 SSL을 채용하는 경우, 통신에 사용하는 포트는 443이 일반적이기 때문에, 통상 URL과 레스큐 URL에서는 IP 어드레스를 변경할 필요가 있다. 따라서, 관리 장치(30) 및 관리대상 기기(40)는 각각 따로따로의 IP 어드레스를 설정할 수 있는 복수의 부분(따로따로의 케이스라도 동일한 케이스라도 좋음)으로 이루어지는 장치로서 구성하게 된다.

이와 같이 한 경우, 통신을 요구받는 쪽(서버로서 기능하는 쪽)은 통신 요구를, 접수한 URL에 의해 구별하여, 통상 URL로 접수한 경우에는 통상 공개키 증명서를 회신하고, 레스큐 URL로 접수한 경우에는 레스큐 공개키 증명서를 회신하도록 할 수 있다.

한편, 통신을 요구하는 클라이언트의 측에서는, 어떤 URL에 대하여 통신 요구를 보냈는지를 알 수 있기 때문에, 상호 인증을 하는 경우에는 그 URL에 따른 적절한 공개키 증명서를 선택하여 송신할 수 있다.

그리고, 관리대상 기기(40)가 관리 장치(30)와 통신하고자 하는 경우에는, 우선 통상 공개키 증명서를 이용한 인증을 시도하지만, 이 인증이 통상 공개키 증명서의 파손이나 유효 기간 경과 등 때문에 실패한 경우, 레스큐 공개키 증명서를 이용한 인증을 시도하도록 하고 있다. 또한, 관리 장치(30)가 통신 상대로서 적당 한 장치이면, 통상은 레스큐 증명서를 이용한 인증이 성공하기 때문에, 관리 장치(30)에는 그 인증이 성공한 경우에, 관리대상 기기(40)의 정규 인증 정보를 갱신하는 기능을 두고 있다.

즉, 관리대상 기기(40)는 관리 장치(30)에 대하여 통신을 요구하는 경우, 우선 통상 URL에 통신 요구를 송신하여 통상 공개키 증명서를 이용한 인증을 하지만, 이것이 실패한 경우에, 이번에는 레스큐 URL에 통신 요구를 송신하여 레스큐 공개키 증명서를 이용한 인증을 한다.

이어서, 관리 장치(30)는 관리대상 기기(40)를 레스큐 공개키 증명서를 이용하여 인증하여, 통신 상대로서 적절하다고 판단한 경우에는, 갱신용의 정규 인증 정보를 발행하여, 관리대상 기기(40)에 송신하여 이것을 기억하도록 요구하도록 하고 있다.

레스큐 공개키 증명서를 이용한 인증이라도, 공통 키의 공유는 통상 공개키 증명서의 경우와 마찬가지로 가능하므로, 증명서 등의 송신은 공유한 공통 키를 이용하여 암호화하여 안전하게 행할 수 있다. 한편, 여기서 송신하는 증명서 등은 도 13에 도시하는 것으로, 관리대상 기기(40)에 기억시키는 정규 인증 정보를 구성하는 것이다. 그리고 물론, 갱신용의 관리대상 기기용 통상 공개키 증명서는 유효 기간 내의 것이다. 한편, 도 13에 도시한 증명서 등을 셋트로 하여, 증명서 셋트로서 송신하도록 하더라도 좋다.

또한 관리대상 기기(40)는, 상기한 요구를 받은 경우에, 수신한 증명서 등을 증명서 설정부(49)에 의해서 증명서 기억부(46)에 기억시켜, 그때까지의 정규 인증 정보를 갱신하도록 하고 있다.

이 갱신이 정상적으로 이루어지면, 관리대상 기기(40)에는 다시 유효 기간 내이며 또 파손되거나 하지 않는 통상 공개키 증명서가 기억되게 되어, 통상 공개키 증명서를 이용한 인증을 할 수 있는 상태가 된다. 따라서 이후에는 통상 공개키 증명서를 이용한 인증을 하여 통신을 실행하도록 하면 된다.

그러나, 이러한 정규 인증 정보의 갱신을 하는 경우에 있어서, 레스큐 공개키 증명서로서, 상술된 바와 같이 발행 대상 장치의 기기 번호가 기재되어 있지 않은 것을 이용하는 경우에는, 통신을 요구하여 온 관리대상 기기(40)의 기기 번호에 관해서, 관리 장치(30)는 통신 경로를 확립한 후에 관리대상 기기(40)가 송신하여 오는 것을 신용하게 된다. 그리고, 이 기기 번호는 예컨대 관리대상 기기(40)가 불휘발 메모리에 기억하고 있는 것인데, 이 정보 자체에는 통상은 디지털 서명과 같은 위조 방지의 조치는 강구되어 있지 않기 때문에, 비교적 용이하게 위조하여, 다른 장치로 위장하는 것이 가능한 상태이다.

따라서, 이 통신 시스템(1000)에 있어서는, 관리 장치(30) 측에, 레스큐 인증 정보를 이용하여 관리대상 기기(40)를 인증한 경우에, 관리대상 기기(40)가 송신하여 오는 기기 번호의 신빙성을 확인하기 위한 검사를 하도록 하고 있다. 그리고, 이 검사는 관리대상 기기(40)에, 인증을 받은 시점에서 기억하고 있는 정규 인증 정보를 송신시켜, 그것이 관리대상 기기(40)가 송신하여 온 기기 번호와 대응하는 것인지의 여부를 조사함으로써 행하도록 하고 있다.

이어서, 이러한 정규 인증 정보와 레스큐 인증 정보의 2종류의 인증 정보를 이용한 증명서의 갱신에 관한 처리에 대해서 설명한다.

우선, 도 14의 시퀀스도에, 갱신 처리 전체의 흐름을 도시한다. 한편 여기서는, 관리대상 기기(40)에 기억하고 있는 관리대상 기기용 통상 공개키 증명서가, 파손 또는 유효 기간의 경과 등에 의해, 인증을 받을 수 없는 상태로 되어 있었던 경우의 처리예를 나타낸다.

이 예에서는, 우선 관리대상 기기(40)가, 관리 장치(30)와 통신할 때에, 통신 요구를 송신하여야 할 URL을 확인하고(S11), HTTPS 클라이언트 기능부(41)를 대(對)관리 장치 클라이언트로서 기능시켜, 확인한 통상 URL에 통신 요구를 송신한다(S12). 이 경우, 관리 장치(30) 측에서는 HTTPS 서버 기능부(32)가 통신 요구를 받아, 인증 처리부(33)에 이 요구를 전한다. 또한, 관리 장치(30)는 통상 공개키 증명서를 이용한 인증을 요구받게 된다. 그리고 인증 처리부(33)는 SSL 프로토콜에 따라서, 증명서 기억부(34)에 기억하고 있는 관리 장치용 통상 개인키로 암호화한 제1 난수와 함께, 마찬가지로 증명서 기억부(34)에 기억하고 있는 관리 장치용 통상 공개키 증명서를 관리대상 기기(40)에 회신한다(S13).

관리대상 기기(40) 측에서는, 이것을 인증 처리부(43)에 건네어 인증 처리를 하는데, 여기서는 수신한 관리 장치용 통상 공개키 증명서의 정당성은 증명서 기억부(46)에 기억하고 있는 관리 장치 인증용 통상 루트 키 증명서를 이용하여 확인할 수 있기 때문에, 인증 성공이라고 판단하고(S14), 증명서 기억부(46)에 기억하고 있는 관리대상 기기용 통상 개인키로 암호화한 제2 난수와 함께, 마찬가지로 증명서 기억부(46)에 기억하고 있는 관리대상 기기용 통상 공개키 증명서를 관리 장치 (30)에 회신한다(S15). 단계(15)에서는, 단계 S13에서 수신한 관리 장치용 통상 공개키를 이용하여 암호화한 공통 키의 시드도 역시 관리 장치(30)에 회신한다.

관리 장치(30) 측에서는, 이들을 인증 처리부(33)에 건네어 인증 처리를 하는데, 여기서는 수신한 관리대상 기기(40)용 통상 공개키 증명서가 인증을 받을 수 없는 상태이기 때문에, 인증 실패라고 판단한다(S16). 따라서, 관리 장치(30)는 관리대상 기기(40)와의 통신을 끊는다.

통신이 끊어지면, 관리대상 기기(40)는 통상 공개키 증명서를 이용하여 인증을 받을 수 없었기 때문에, 이번에는 레스큐 URL에 통신 요구를 송신한다(S17, S18). 이어서, 관리대상 기기(40)는 레스큐 공개키 증명서를 이용하여 관리 장치(30)와의 상호 인증을 시도한다(S19∼S21). 한편, 이 처리의 내용은 이용하는 인증 정보의 종류가 다를 뿐이며, 단계 S13∼S15의 경우와 동일한 처리이므로 설명을 생략한다.

그리고, 이번에는 인증이 성공하기 때문에(S22), 관리 장치(30)는 그러한 취지의 응답을 관리대상 기기(40)에 회신한다(S23). 그렇게 하면, 관리대상 기기(40)는 그것에 따라서 기기 번호 등 및 증명서 기억부(46)에 기억하고 있는 정규 인증 정보를 관리 장치(30)에 송신한다(S24). 그리고, 관리 장치(30)의 증명서 검사부(35)가 이들 정보를 바탕으로 관리대상 기기(40)를 검사하여, 갱신용의 증명서를 발행하여도 된다고 판단하면(S25), 증명서 발행부(36)가 갱신용의 증명서를 발행하는 동시에, 증명서 기억부(34)의 증명서 데이터베이스에 발행한 공개키 증명서나 발행처 장치의 식별 정보 등을 등록한다(S26).

그 후, 증명서 설정 커맨드와 함께 발행한 갱신용 증명서를 관리대상 기기(40)에 전송한다(S27).

그렇게 하면, 관리대상 기기(40)는, 증명서 설정 커맨드에 첨부된 갱신용 증명서를, 관리 장치(30)와의 통신을 할 때에 사용하는 정규 인증 정보로서 설정하고(S28), 설정 결과에 대해서 관리 장치(30)에 응답을 회신한다(S29). 이상으로, 레스큐 인증 정보를 이용한 관리대상 기기(40)의 통상 증명서 갱신의 처리가 종료된다.

한편, 이상의 처리에 있어서, 갱신용 증명서와 함께 개인키나 루트 키 증명서의 발행이나 설정을 할 필요가 있으면, 이들도 함께 발행이나 설정을 하도록 하여, 발행이나 설정을, 공개키 증명서와 개인키와 루트 키 증명서를 셋트로 한 증명서 셋트의 형태로 행하도록 하더라도 좋다.

도 1에 도시한 통신 시스템(1000)에 있어서는, 관리대상 기기(40)에 있어서 정규 인증 정보를 구성하는 공개키 증명서가 인증을 받을 수 없는 상태가 되어 버린 경우라도, 이상의 처리에 의해, 관리대상 기기(40)의 증명서를 갱신하여 인증이 정상적으로 이루어지는 상태로 회복시키도록 하고 있다. 또한, 정규 인증 정보를 구성하는 개인키나 루트 키 증명서가 파손되거나 한 경우라도, 단계 S11 내지 S16에서의 인증 처리가 실패하는 단계가 다를 뿐이며, 단계 S17 이후에 대해서는 전술한 처리와 마찬가지다.

그 다음, 관리 장치(30)의 증명서 기억부(34)에 설치하는 증명서 데이터베이스의 데이터 구조를 설명한다.

도 15 및 도 16에 도시한 바와 같이, 증명서 데이터베이스는 2개의 테이블을 포함하고 있다. 그리고, 도 15에 도시한 제1 테이블에는, 공개키 증명서의 발행처 장치(관리대상 기기)의 식별 정보인 기기 번호와, 그 장치에 발행한 최신의 공개키 증명서의 시리얼 번호(이하 단순히 「시리얼」이라고도 함) 및 그 공개키 증명서의 발행 일시의 정보를 대응시켜 등록하고 있다.

또한, 도 16에 도시하는 제2 테이블에는, 공개키 증명서의 시리얼과, 그 공개키 증명서의 내용을 대응시켜 등록하고 있다. 여기서는, 공개키 증명서의 내용으로서, 도 7에 도시한 것과 같은 서지 사항을 포함하는 공개키 증명서를 그대로 등록하도록 하고 있지만, 이에 덧붙여서 또는 이것 대신에, 유효 기한이나 발행처 장치의 국가나 지역 등, 서지 정보 중의 소정의 항목을 추출하여 등록하도록 하더라도 좋다.

그리고, 제2 테이블에는, 공개키 증명서를 발행한 시점에서 그 증명서의 등록을 하고, 제1 테이블의 내용은, 관리대상 기기(40)로부터 설정 성공의 응답이 있었던 후에 갱신하도록 하면 좋다.

이상과 같은 테이블을 준비함으로써, 관리 장치(30)는, 관리대상 기기(40)의 기기 번호를 키로, 그 장치가 기억하고 있을 공개키 증명서(설정이 실패하고 있지 않다면, 그 장치에 발행한 최신의 공개키 증명서임)를 증명서 데이터베이스로부터 취득할 수 있다.

한편, 도 15 및 도 16에 도시한 바와 같이 테이블을 2개 준비한 것은, 관리대상 기기(40)에 새로운 공개키 증명서를 발행한 경우라도, 과거에 발행한 것도 포 함시켜, 모든 공개키 증명서를 기억해 두도록 하기 위해서이다. 또한, 개인키에 대해서는, 발행처의 장치 이외에 유지해 두는 것은 바람직하지 못하기 때문에, 여기서는 테이블에 등록하지 않도록 하고 있다. 루트 키 증명서에 대해서는, 다수의 관리대상 기기(40)에 관해서 같은 것을 기억시키고 있으므로, 도시하지 않는 별도의 테이블로 관리하여, 공개키 증명서 중의, 증명서의 버전 정보를 키로 취득할 수 있도록 하여, 데이터량의 저감을 도모하고 있다.

이어서, 도 14에 도시한 것과 같은 갱신 처리를 하는 경우에 관리대상 기기(40)가 실행하는 처리에 대해서 보다 상세히 설명한다. 도 17에, 그 처리의 흐름도를 도시한다. 이 처리는 관리대상 기기(40)의 CPU가 사전설정된 제어 프로그램을 실행하여 행하는 것이다.

관리대상 기기(40)는 관리 장치(30)에 대하여 커맨드나 통지를 송신하거나, 관리 장치(30)로부터의 커맨드나 통지를 수취하기 위해서 폴링을 하거나 하는 경우, 도 17의 흐름도에 도시하는 처리를 시작하여, 우선 단계 S41에서 관리 장치(30)의 통상 URL에 대하여 통신 요구를 송신한다. 한편, 관리대상 기기(40)는 통신 상대가 되는 관리 장치(30)에 대해서, 통신 요구처로서 통상 URL과 레스큐 URL을 기억하고 있는 것으로 한다.

후속해서, 단계 S42에서, 관리 장치(30)와의 사이에서 통상 공개키 증명서 및 난수나 공통 키의 시드를 송수신하여, 도 1에 도시한 것과 같은 SSL에 의한 상호 인증 처리를 한다. 그리고, 단계 S43에서 이 인증이 성공했는지의 여부를 판단하여, 성공하고 있으면, 관리 장치(30)와의 사이에서 통신을 확립하여 단계 S44 이 하로 진행하여 통상의 통신에 따른 처리를 한다. 한편, 단계 S42에서의 인증은 상호 인증이 바람직하지만, 적어도 관리 장치(30)가 관리대상 기기(40)를 인증할 수 있으면, 상호 인증이라도 한방향 인증이라도 상관없다.

단계 S44에서, 단계 S42의 인증 처리에서 송신한 공통 키의 시드로부터 공통 키를 생성한다. 후속해서, 단계 S45에서 커맨드 및 수신한 커맨드에 대한 응답을 그 공통 키로 암호화하여 통신 중인 장치(여기서는 관리 장치(30))에 송신하고, 단계 S46에서 커맨드 및 송신한 커맨드에 대한 응답을 동일한 공통 키로 암호화된 상태로 통신 중인 장치로부터 수신한다. 그리고, 단계 S47에서 커맨드 및 응답을 전부 송수신했는지의 여부를 판단한다. 그리고, 아직 남아 있으면 단계 S45로 되돌아가 처리를 반복하고, 전부 송수신하고 있으면, 관리대상 기기(40)는 단계 S48로 진행하여 관리 장치(30)와의 통신을 끊고, 도 17에 도시된 처리를 종료한다.

한편, 단계 S45 및 S46의 처리는 순서가 같지 않더라도 상관없으며, 송수신하여야 할 커맨드나 응답이 없으면 생략한다. 또한, 수신한 커맨드에 관한 처리를 실행하여 응답을 생성하는 처리나, 수신한 응답의 내용을 해석하여 그것에 대응한 동작을 하는 처리는 수신한 커맨드나 응답을 기억해 두고서, 도 17에 도시한 흐름도와는 별도로 실행하는 것으로 한다.

한편, 단계 S43에서 인증이 실패한 경우에는, 단계 S49 이하로 진행하여, 레스큐 인증 정보를 이용하여 갱신용 증명서의 취득을 시도하는 처리를 한다. 한편, 인증 실패의 원인이 통신 이상 등, 증명서의 이상에 기인하지 않는 것인 경우에는 이 처리를 하지 않도록 하더라도 좋다.

단계 S49 이후의 처리에 있어서는, 우선 단계 S49에서, 관리대상 기기(40)는 관리 장치(30)의 레스큐 URL에 대하여 통신 요구를 송신한다. 그리고, 단계 S50에서, 관리 장치(30)와의 사이에서 레스큐 공개키 증명서 및 난수나 공통 키의 시드를 송수신하여, 도 1에 도시한 것과 같은 SSL에 의한 상호 인증 처리를 한다.

단계 S51에서, 이 인증이 성공했는지의 여부를 판단한다. 여기서 인증이 실패한 경우에는 그대로 단계 S48에서 통신을 절단하여 처리를 종료하지만, 인증이 성공하고 있으면, 관리 장치(30)와의 사이에서 통신을 확립하고 단계 S52 이하로 진행하여, 갱신용 증명서의 취득과 설정에 관한 처리를 한다.

즉, 우선 단계 S52에서, 단계 S50의 인증 처리에서 송신한 공통 키의 시드로부터 공통 키를 생성한다. 그리고, 단계 S53에서, 그 공통 키로 암호화한 기기 번호 등의 정보를 관리 장치(30)에 송신하는 동시에, 단계 S54에서, 증명서 기억부(46)에 기억하고 있는 정규 인증 정보를 동일한 공통 키로 암호화하여 관리 장치(30)에 송신한다. 이들 단계 S53 및 S54의 송신은 필요한 정보를 하나의 메시지에 기재하여 행하더라도 좋다.

단계 S53 및 S54에서 송신한 정보는, 관리 장치(30)가, 관리대상 기기(40)에 갱신용의 증명서를 발행하여도 되는지의 여부를 확인하기 위한 검사를 하기 위해서 사용되며, 또한 갱신용의 증명서에 기재하는 관리대상 기기(40)의 식별 정보로서도 사용된다.

또한, 단계 S53에서 송신하는 기기 번호 이외의 정보로서는, 예컨대 그때까지의 정규 인증 정보를 사용할 수 없게 된 원인의 통지를 생각할 수 있다. 그리고, 통지하는 원인으로서는 예컨대, 증명서 기억부(46)를 구성하는 메모리 유닛을 교환했다, 장치가 네트워크에 접속되어 있지 않기 때문에 증명서의 자동 갱신을 할 수 없었다, 증명서의 갱신 중에 전원을 껐기 때문에 데이터가 파괴되었다, 등을 생각할 수 있다.

또한, 단계 S54에서 송신하는 정규 인증 정보는 단계 S42의 처리에 있어서 인증 처리에 사용하고자 한 것으로, 파손되어 있거나, 공개키 증명서의 유효 기한이 끊겨 있거나, 정상적으로 인증을 받을 수 없는 상태로 되어 있는 것이다. 그러나, 여기서 송신하는 것은, 관리 장치(30)에 있어서의 검사에 사용하게 하기 위해서이며, 검사의 기준은 SSL에 의한 인증 처리의 경우와는 다르기 때문에, 이러한 상태라도 상관하지 않고서 송신한다. 또한, 개인키는 원래는 다른 장치에 송신하지 않는 것이지만, 여기서는 이미 대응하는 공개키 증명서가 인증에 사용할 수 없는 상태로 되어 있으므로, 송신에 의해 개인키가 다른 장치에 알려져 버렸다고 해도 특별히 문제없다.

또한, 정규 인증 정보에는 도 8에 도시한 바와 같이 공개키 증명서와 개인키와 루트 키 증명서가 포함되는데, 이들 모두를 송신하는 것은 필수적이지 않다. 더욱이, 정규 인증 정보의 전부 또는 일부에 누락이 있는 경우에는, 누락되어 있다는 취지의 정보를 송신하도록 하더라도 좋고, 단순히 누락되어 있는 정보를 송신하지 않도록 할 뿐인 것으로 하더라도 좋다.

단계 S54 후에는 단계 S55에서, 관리대상 기기(40)는 관리 장치(30)로부터의 증명서 설정 커맨드의 수신을 기다린다. 상술한 바와 같이, 레스큐 공개키 증명서 를 이용한 인증을 한 경우에는 이외의 요구에 관한 동작은 하지 않도록 하고 있다.

관리대상 기기(40)가 증명서 설정 커맨드를 수신하면, 관리대상 기기(40)는 단계 S56으로 진행하여, 증명서 설정 커맨드와 함께 수신한 증명서를 기억하여, 이것을 관리 장치(30)와의 통신에 사용하는 정규 인증 정보로서 설정한다.

이것이 완료되면, 단계 S57에서 관리대상 기기(40)는 관리 장치(30)에게 응답을 회신하고, 그 다음 관리 장치(30)와의 통신을 끊고, 자신을 재기동한다. 이 재기동은 관리대상 기기(40)에 있어서 중요한 설정을 변경할 때에 필요한 것으로, 여기서는 증명서의 설정이 이것에 해당한다. 재기동을 할 때에, 사용자에게 재기동의 허가를 요구하도록 하더라도 좋다. 도 17에는 이 처리가 단계 S58 이후에 종료하는 것으로 도시되어 있지만, 실제로는 단계 S58에서의 관리대상 기기(40)가 재기동할 때 종료된다. 또한, 재기동없이, 그대로 처리를 종료하도록 하더라도 좋다.

도 17에서, 관리대상 기기(40)의 통상 공개키 증명서가 파손 또는 기한 마감 등으로 된 경우의 증명서의 갱신에 관해서 설명했지만, 그 이외의 경우라도, 증명서의 갱신시에 관리 장치(30)가 관리대상 기기(40)를 검사하는 것이 바람직한 경우가 있다.

도 18에, 또 다른 경우의 정규 인증 정보의 갱신 처리 전체의 흐름을 도시한다.

이 예에서는, 관리대상 기기(40)는, 관리 장치(30)와의 사이의 인증 처리에 사용하는 공개키 증명서의 유효 기한의 일정 기간 전이 되었음을 검출하면(S61), 정규 인증 정보의 갱신 시기가 되었다고 판단하여, 관리 장치(30)에 대하여 갱신용 의 공개키 증명서 등의 송신을 요구하는 증명서 요구 커맨드를, 도 17의 단계 S45에 의한 통상의 커맨드 송신시에 관리 장치(30)에 송신하는 커맨드로서 등록해 둔다.

그 후, 적당한 타이밍에 관리대상 기기(40)가 관리 장치(30)의 통상 URL에 통신을 요구하고, 그 때, 정규 인증 정보를 이용하여 상호 인증을 하는데, 여기서는 인증 정보에 특별히 문제는 없다고 하면, 상세한 설명은 도 14의 설명과 중복되기 때문에 생략하지만, 인증 처리는 성공한다(S71∼S77). 한편, 여기서 사용하는 관리대상 기기(40)의 공개키 증명서는 공통 공개키 증명서이다.

그리고, 인증이 성공하면, 관리대상 기기(40)는 관리 장치(30)에 대하여, 단계 S62에서 등록하고 있는 증명서 요구 커맨드를 송신한다(S78). 또한 이 때, 기기 번호 등 및 증명서 기억부(46)에 기억하고 있는 정규 인증 정보도 관리 장치(30)에 송신한다. 이들은, 예컨대 증명서 요구 커맨드의 인수로서 송신할 수 있다.

그리고, 관리 장치(30)의 증명서 검사부(35)가 이들 정보를 바탕으로 관리대상 기기(40)를 검사하여, 갱신용의 증명서를 발행하여도 된다고 판단하면(S79), 증명서 발행부(36)가 갱신용의 증명서를 발행하는 동시에, 증명서 기억부(34)의 증명서 데이터베이스에 발행한 공개키 증명서나 발행처 장치의 식별 정보 등을 등록한다(S80).

그 후, 증명서 설정 커맨드와 함께 발행한 갱신용 증명서를 관리대상 기기(40)에 전송한다(S81).

그렇게 하면, 관리대상 기기(40)는 증명서 설정 커맨드에 첨부된 갱신용 증 명서를, 관리 장치(30)와의 통신을 할 때에 사용하는 정규 인증 정보로서 설정하고 (S82), 설정 결과에 대해서 관리 장치(30)에 응답을 회신한다(S83).

이상으로, 관리대상 기기(40)의 통상 증명서 갱신 처리가 종료된다. 한편, 단계 S80에서 발행하는 증명서는, 단계 S78에서 수신한 기기 번호를 발행처 장치의 식별 정보로서 기재한 개별 공개키 증명서로 하면 된다. 또한, 관리대상 기기(40)는 단계 S81에서의 증명서 갱신 커맨드를, 도 17의 단계 S46에 나타낸 통상의 커맨드 수신 처리에 의해 수신하여, 수신한 커맨드에 관한 처리를 실행하도록 할 수 있다.

이어서, 도 19 및 도 20에, 도 14 내지 도 18을 이용하여 설명하여 온 정규 인증 정보의 갱신 처리에 있어서의, 관리 장치(30) 측의 처리의 흐름도를 도시한다. 이 처리는 관리 장치(30)의 CPU(11)가 레스큐 URL에 통신 요구를 받은 경우에 시작하는 것으로, 사전설정된 제어 프로그램을 실행하여 행하는 것이다. 또한, 단계 S95 이후의 처리에 대해서는, 통상 URL에 통신 요구를 받아, 일반적인 커맨드 송수신에 있어서 증명서 요구 커맨드를 수신한 경우에 실행하는, 이 커맨드에 관련한 처리와 공통인 것이다. 한편, 관리 장치(30)의 CPU가 통상 URL에 통신 요구를 받은 경우에 행하는 일반적인 커맨드 송수신에 관련한 처리에 대해서는, 도 19 및 도 20에 도시하는 처리와는 독립된 일반적인 처리이기 때문에, 여기서는 설명을 생략한다.

도 19에 도시하는 처리에 있어서는, 관리 장치(30)의 CPU(11)는 우선 단계 S91에서, 통신 요구의 요구원 장치(여기서는 관리대상 기기(40))와의 사이에서 레 스큐 공개키 증명서 및 난수와 공통 키의 시드를 송수신하여, 도 1에 도시한 것과 같은 SSL에 의한 상호 인증 처리를 한다.

그리고, 관리 장치(30)는 단계 S92에서 이 인증이 성공했는지의 여부를 판단한다. 여기서 인증이 실패한 경우에는 그대로 도 20의 단계 S108로 진행하여 통신을 끊고 처리를 종료하지만, 인증이 성공하고 있으면, 통신 요구의 송신원과의 사이에서 통신을 확립하여 단계 S93 이하로 진행하여, 통신 요구의 송신원 검사 및 갱신용 증명서의 설정에 관한 처리를 한다. 또한, 인증이 성공한 시점에서, 통신 요구의 송신원이 어느 한 관리대상 기기임을 알 수 있다. 여기서는 통신 요구의 송신원이 관리대상 기기(40)라고 하고 이후의 설명을 한다.

이 처리에 있어서는, 우선 단계 S93에서, 단계 S91의 인증 처리에서 수신한 공통 키의 시드로부터 공통 키를 생성한다. 그리고, 단계 S94에서, 그 공통 키로 암호화된 기기 번호 등 및 정규 인증 정보를 관리대상 기기(40)로부터 수신한다. 다만, 관리대상 기기(40)가 정규 인증 정보의 모두를 송신하여 오는 것은 아닌 경우에는, 송신하여 온 것만을 수신하게 되어, 여기서 정규 인증 정보를 전혀 수신할 수 없는 경우도 있을 수 있다.

이 단계 S94의 처리가 수신 순서의 처리이며, 이 처리에 있어서는 관리 장치(30)의 CPU(11)가 수신 수단으로서 기능한다.

단계 S94 후에는, 관리 장치(30)는 단계 S95로 진행하여, 단계 S94에서 수신한 기기 번호에 관해서, 그 기기 번호가 통신 상대로서 적절한 장치의 것인지의 여부를 판단한다. 이 처리를, 증명서 요구 커맨드(송신원은 관리대상 기기(40)로 함) 에 관련한 처리로서 실행하는 경우에는, 증명서 요구 커맨드와 함께 수신한 기기 번호에 관해서 이 판단을 한다.

그리고, 관리대상 기기(40)가 적절한 통신 대상이 아니라면, 이후의 검사를 할 필요도 없고, 관리대상 기기(40)에 갱신용 증명서를 발행해야 하는 것이 아님을 알 수 있다. 그래서, 그대로 도 20의 단계 S109로 진행하여, 검사 불합격의 취지 및 그 이유를 기재한 메시지를 관리대상 기기(40)에 송신하는 동시에, 단계 S110에서 관리 장치(30)의 오퍼레이터에게도 검사 불합격의 취지 및 그 이유를 통지하고, 통신을 끊어 처리를 종료한다. 이와 같이 되는 케이스로서는 예컨대, 관리대상 기기(40)가 관리 장치(30)에 의한 관리의 대상으로 될 수 있는 장치이지만, 관리 계약이 맺어져 있지 않은 등의 이유에 의해 관리 장치(30)에 관리 대상으로서 등록되어 있지 않은 경우 등을 생각할 수 있다.

한편, 단계 S95에서 관리대상 기기(40)가 적절한 통신 대상이라면, 단계 S96으로 진행하여, 단계 S94에서(또는 증명서 요구 커맨드와 함께, 이하 동일함) 수신한 기기 번호를 키로 증명서 기억부(34)의 증명서 데이터베이스(도 15 및 도 16에 도시된 2개의 테이블 참조)를 검색하여, 그 기기 번호의 장치가 기억하고 있을 최근의 통상 공개키 증명서 및 통상 루트 키 증명서의 정보를 취득한다. 이 취득은 물론 관리대상 기기(40)와는 다른 장소에서 하는 것이다. 또한, 여기서 취득하는 것은 공개키 증명서나 루트 키 증명서의 전체라도 일부분이라도, 이들로부터 증명서의 시리얼 번호, 발행처 장치의 식별 정보, 유효 기한, 발행일 등의 필요한 정보를 추출한 것이라도 좋다. 단계 S97 내지 S99에서의 검사에 필요한 정보를 취득하 면 충분하다. 또한, 여기서 취득하는 공개키 증명서가 상술한 공통 공개키 증명서인 경우도 있다.

이 단계 S96의 처리가 취득 순서의 처리이며, 이 처리에 있어서는 관리 장치(30)의 CPU(11)가 취득 수단으로서 기능한다.

다음의 단계 S97은 단계 S94에서 수신한 공개키 증명서를 이용한 검사의 처리이며, 단계 S94에서 관리대상 기기(40)로부터 수신한 공개키 증명서와, 단계 S96에서 취득한 정보를 이용하여 관리대상 기기(40)를 검사하여 그 결과를 결과 테이블에 등록한다. 이 공개키 증명서를 이용한 검사를 어떻게 할지에 대해서는 여러 가지 방식을 생각할 수 있는데, 적어도, 단계 S94에서 공개키 증명서를 수신한 경우에는, 그 공개키 증명서가, 동 단계에서 수신한 기기 번호의 장치가 기억하고 있는 공개키 증명서로서 적절한 것인지의 여부를 판단할 수 있도록 행하는 것으로 한다. 예컨대, 관리대상 기기(40)로부터 수신한 공개키 증명서와 증명서 데이터베이스로부터 취득한 공개키 증명서와의 전체를 비교하거나, 이들의 일부를 비교하거나, 양 증명서로부터 파라메터를 추출하여 비교하거나, 양 증명서의 내용이 일치한 경우에 적절한 것인 것으로 할 수 있다.

도 21의 흐름도에, 단계 S97에서의 공개키 증명서를 이용한 검사 처리의 일례를 도시한다.

이 처리에 있어서는, 우선 단계 S111에서, 도 19의 단계 S94에서 관리대상 기기(40)로부터 정규 인증 정보로서 공개키 증명서를 수신했는지의 여부를 판단한다. 그리고, 수신하고 있으면, 단계 S112로 진행하여, 수신한 공개키 증명서와, 도 19의 단계 S96에서 증명서 데이터베이스로부터 취득한 공개키 증명서가 일치하는지의 여부를 판단한다.

그리고, 일치하고 있으면, 단계 S94에서 수신한 공개키 증명서는 관리대상 기기(40)가 기억하고 있을 것인 것으로, 이것은 통신 상대가 관리대상 기기(40)임을 지지하는 근거가 되기 때문에, 단계 S113에서 결과 테이블에 공개키 증명서의 검사 결과로서 「OK」를 등록하고 원래의 처리로 되돌아간다. 일치하지 않고 있으면, 반대로 통신 상대가 관리대상 기기(40)가 아님을 지지하는 근거가 되기 때문에, 단계 S114에서 검사 결과로서 「NG」를 등록하고 원래의 처리로 되돌아간다.

또한, 단계 S111에서 공개키 증명서를 수신하지 않고 있으면, 단계 S115에서 공개키 증명서의 검사 결과로서 「없음」을 등록하고서 원래의 처리로 되돌아간다.

도 19의 단계 S97에서의 검사 처리는, 예컨대 이상과 같은 처리에 의해 행할 수 있다.

일반적으로 공개키 증명서는 비밀로 유지하는 데이터가 아니라, 적절하게 통신 상대에게 송신하여 버리는 데이터이기 때문에, 공개키 증명서를 기억하고 있는 것은 그 공개키 증명서의 발행처의 장치인 것의 근거로 되기는 어렵다.

그러나, 특정한 통신 상대하고만 통신하고, 따라서 공개키 증명서도 특정한 장치에게밖에 건네지 않는 통신 시스템에 있어서는, 전혀 무관계한 장치가 관리대상 기기(40)의 공개키 증명서를 기억하고 있을 가능성은 낮다. 또한, 관리대상 기기(40)의 통신 상대가 되는 장치가, 관리대상 기기(40)와 동일한 벤더의 제품인 경우에는 통신 상대의 측에서는 공개키 증명서를 보존하지 않도록 하거나, 다른 장치 에 전송하지 않도록 하거나 하는 대응이 가능하게 된다.

예컨대, 관리대상 기기(40)가 방화벽의 내측에 있는 것을 전제로 하여 시스템을 구축하여, 관리대상 기기(40)와 관리 장치(30) 사이의 통신은 반드시 관리 대상 장치(40)가 발호측이 되도록 행하고, 또한 관리 대상 장치(40)가 관리 장치(30) 이외에 대해서는 통신을 요구하지 않도록 하면, 관리대상 기기(40)의 공개키 증명서가, 관리 장치(30) 이외의 장치에 대하여 송신되지 않도록 할 수 있다. 또한, 관리대상 기기(40)에 있어서, 공개키 증명서를, 기판에 고정된 플래시 ROM이나 EPROM 등의 메모리에 스크램블된 상태로 보존하도록 하면, 오프라인에서의 증명서의 부담도 방지되어, 관리대상 기기(40)의 공개키 증명서가 자신과 관리 장치(30) 이외의 장치에 기억되는 사태를 한층 더 효과적으로 방지할 수 있다.

따라서, 이러한 경우에는, 관리 장치(30) 측에서 특정한 기기 번호의 장치가 기억하고 있다고 파악하고 있는 공개키 증명서를 송신하여 오는 장치는 정말로 그 기기 번호의 장치일 가능성이 높다고 할 수 있다. 특히, 관리대상 기기(40)의 통신 상대가 관리 장치(30)만인 경우에는, 관리대상 기기(40)에 대하여 발행한 공개키 증명서는 관리대상 기기(40)와 관리 장치(30)만이 기억하고 있을 것이므로, 관리 장치(30) 측에서 파악하고 있는 것과 동일한 공개키 증명서를 송신하여 오는 것을 가지고, 대응하는 기기 번호의 장치라고 판단하도록 하는 것도 생각할 수 있다.

또한, 도 22의 흐름도에, 단계 S97에서의 공개키 증명서를 이용한 검사 처리의 별도의 예를 도시한다. 이 처리는 증명서 요구 커맨드에 따른 처리를 할 때에 적용하기에 적합한 예이다.

도 22의 검사 처리에 있어서는 우선, 단계 S121 및 단계 S122에서, 도 21의 단계 S111및 S112의 경우와 같은 식의 검사를 한다.

그 후, 관리대상 기기(40)로부터 수신한 기기 번호나, 수신한 공개키 증명서의 유효 기한의 정보를 이용하고, 이들 정보를 키로 하여 관리 대상으로 하는 장치에 관한 정보를 기록하고 있는 도시하지 않는 테이블을 참조하여, 관리대상 기기(40)가 관리 대상의 장치인지의 여부 및 관리대상 기기(40)에 대해서 관리 계약 기간이 사용 중인 공개키 증명서의 유효 기한 후에까지 있는지의 여부를 판단한다(S123, S124).

그리고, 관리 대상의 장치 이외에 대해서는, 앞으로도 통신이 가능한 상태로 해 둘 필요는 없으며, 관리 계약 기간이 사용 중인 공개키 증명서의 유효 기한 내에서 종료되는 것이라면, 그 후 통신이 가능한 상태로 해 둘 필요는 없기 때문에, 단계 S123 또는 S124의 판단이 NO인 경우는 단계 S127에서 검사 NG(불합격)으로 하여 이하의 처리로 진행한다.

한편, 단계 S124에 대해서는, 공개키 증명서의 유효 기한을 관리 계약의 기한을 바탕으로 정해 놓은 경우에는, 관리 연장 계약이 이루어져 있는지의 여부를 기준으로 판단하도록 하더라도 좋다.

또한, 단계 S123과 S124에서 YES라면, 단계 S125로 진행하여, 현재의 공개키 증명서가 기한 마감에 임박(예컨대 유효 기한까지 1개월 이내)했는지의 여부를 판단한다. 증명서 요구 커맨드는 공개키 증명서의 기한 마감에 임박하여 송신되어 올 것이므로, 이 판단이 NO인 경우에는 어떠한 이상이 발생하고 있다고 생각되며, 역 시 단계 S127에서 검사 NG로 하여 원래의 처리로 되돌아간다.

또한, 이상의 단계 S121 내지 S125의 판단이 전부 YES라면, 단계 S126에서 검사 OK(합격)로 하여 원래의 처리로 되돌아간다.

이상의 처리에 의해, 기기 번호의 송신원 장치를 검사하여, 공개키 증명서를 발행하여도 좋은지의 여부를 판단할 수 있다. 한편, 검사 처리에 있어서 판단하여야 할 항목에 대해서는 도 21이나 도 22에 도시한 것은 일례에 지나지 않으며, 관리대상 기기(40)의 용도나 관리 장치(30)에 의한 관리의 운용 형태 등에 따라서 적절하게 정하면 되는 것은 물론이다.

도 19의 설명으로 되돌아간다. 단계 S98은 단계 S94에서 수신한 개인키를 이용한 검사의 처리이며, 단계 S94에서 관리대상 기기(40)로부터 수신한 개인키와, 단계 S96에서 취득한 정보를 이용하여 관리대상 기기(40)를 검사하여 그 결과를 결과 테이블에 등록한다. 이 개인키를 이용한 검사를 어떻게 행하는지에 관해서도 여러 가지 방식을 생각할 수 있지만, 적어도 단계 S94에서 개인키를 수신한 경우에는, 그 개인키가, 같은 단계에서 수신한 기기 번호의 장치가 기억하고 있는 공개키와 대응하는 것인지의 여부를 판단할 수 있도록 하는 것으로 한다. 예컨대, 관리대상 기기(40)로부터 수신한 개인키와 증명서 데이터베이스로부터 취득한 공개키 증명서 중의 공개키의 한 쪽을 이용하여 적당한 데이터를 암호화하고, 다른 쪽을 이용하여 그 암호화한 데이터를 복호화하여, 복호화에 의해 원래의 데이터를 얻을 수 있었던 경우에 적절한 것으로 할 수 있다.

도 23의 흐름도에, 단계 S98에서의 개인키를 이용한 검사 처리의 일례를 도 시한다.

이 처리에서는, 우선 단계 S141에 있어서, 도 19의 단계 S94에서 관리대상 기기(40)로부터 정규 인증 정보로서 개인키를 수신했는지의 여부를 판단한다. 그리고, 수신하고 있으면, 단계 S142로 진행하여, 수신한 개인키를 이용하여 적당한 데이터를 암호화하고, 단계 S143에서, 그 암호화한 데이터를, 도 19의 단계 S96에서 증명서 데이터베이스로부터 취득한 공개키 증명서 중의 공개키를 이용하여 복호화한다. 한편, 이 때 복호화에 관리대상 기기(40)로부터 수신한 공개키 증명서 중의 공개키를 이용하면, 단순히 관리대상 기기(40)에 상호 대응하는 공개키와 개인키가 기억되어 있음을 확인하는 것으로밖에 되지 않기 때문에 주의가 필요하지만, 이와 같이 하는 것도 생각할 수 있다.

그리고, 단계 S144에서 이 복호화가 성공했는지의 여부, 즉 복호화의 결과 암호화하기 전의 데이터를 얻을 수 있었는지의 여부를 판단한다.

원래의 데이터를 얻을 수 있으면, 단계 S94에서 수신한 개인키는 관리대상 기기(40)가 기억하고 있다고 관리 장치(30) 측에서 파악하고 있는 공개키와 대응하는 것으로, 이것은 통신 상대가 관리대상 기기(40)임을 지지하는 근거가 된다. 그래서, 단계 S145에서 결과 테이블에 개인키의 검사 결과로서 「OK」를 등록하고 원래의 처리로 되돌아간다. 원래의 데이터를 얻을 수 없으면, 반대로 통신 상대가 관리대상 기기(40)가 아님을 지지하는 근거가 되기 때문에, 단계 S146에서 검사 결과로서 「NG」를 등록하고 원래의 처리로 되돌아간다.

또한, 단계 S141에서 개인키를 수신하고 있지 않으면, 단계 S147에서 개인키 의 검사 결과로서 「없음」을 등록하고 원래의 처리로 되돌아간다.

도 19의 단계 S98에서의 검사 처리는 예컨대 이상과 같은 처리에 의해 행할 수 있다.

개인키는 통상은 발행 대상의 장치밖에 기억하고 있지 않은 데이터이다. 따라서, 어떤 기기 번호의 장치가 기억하고 있다고 파악하고 있는 개인키를 송신하여 오는 장치는 정말로 그 기기 번호의 장치일 가능성이 높다고 말 할 수 있다. 그러나, 비교를 위해 각 장치에 발행한 개인키를 관리 장치(30) 측에서 기억해 두고자 하면, 관리 장치(30)가 관리대상 기기(40)로 위장하는 것이 가능하게 되어 버려, 시스템의 설계상 바람직하지 못하다. 그래서, 도 23에 도시한 예에서는, 수신한 개인키가, 어떤 기기 번호의 장치가 기억하고 있다고 파악하고 있는 공개키와 대응하는 것을 확인함으로써, 그 개인키가 그 기기 번호의 장치가 기억하고 있을 것임을 간접적으로 확인하도록 하고 있다.

그러나, 증명서 데이터베이스에 개인키도 기억해 두고서, 관리대상 기기(40)로부터 수신한 개인키와 증명서 데이터베이스로부터 취득한 개인키를 비교하도록 하는 것도 기술적으로는 가능하다.

재차 도 19의 설명으로 되돌아간다. 단계 S99는 단계 S94에서 수신한 루트 키 증명서를 이용한 검사의 처리이며, 단계 S94에서 관리대상 기기(40)로부터 수신한 루트 증명서와, 단계 S96에서 취득한 정보를 이용하여 관리대상 기기(40)를 검사하여 그 결과를 결과 테이블에 등록한다. 이 루트 키 증명서를 이용한 검사를 어떻게 행할지에 관해서도 여러 가지 방식을 생각할 수 있지만, 그 사고 방식은 공개 키 증명서의 경우와 마찬가지이므로, 상세한 설명은 생략한다. 처리의 구체적인 예로서도, 도 18에 도시한 흐름도의 처리 중, 「공개키 증명서」의 부분을 「루트 키 증명서」라고 바꿔 읽은 처리를 채용하는 것이 가능하다.

루트 키 증명서도, 공개키 증명서의 경우와 마찬가지로, 일반적으로는 비밀로 유지하는 데이터가 아니다. 또, 관리대상 기기(40)와 동일한 계위에 속하는 장치에는 공통으로 기억시켜 두는 것이다. 따라서, 루트 키 증명서를 기억하고 있다고 해서 그 장치가 특정한 장치라고 판단하기는 어렵다.

그러나, 한번 설정된 루트 키 증명서는 통상은 외부의 장치에 송신하는 것은 아니기 때문에, 전혀 무관계한 장치가 관리대상 기기(40)의 루트 키 증명서를 기억하고 있을 가능성은 낮다. 따라서, 이러한 경우에는, 관리 장치(30) 측에서 특정한 계위의 장치가 기억하고 있다고 파악하고 있는 루트 키 증명서를 송신하여 오는 장치는 적어도 정말로 그 계위의 장치일 가능성이 높다고 말할 수 있다.

또한, 복수 버전의 공개키 증명서와 대응하는 루트 키 증명서가 혼재하고 있는 경우, 통신 상대가 관리 장치(30) 측에서 파악하고 있는 공개키 증명서와 대응하는 루트 키 증명서를 송신하여 오면, 이것은 통신 상대가 정말로 송신하여 온 기기 번호의 장치임을 지지하는 증거가 된다.

따라서, 루트 키 증명서를 이용한 검사의 결과도, 공개키 증명서나 개인키를 이용한 검사보다는 신뢰성이 떨어지지만, 공개키 증명서나 개인키를 이용한 검사의 결과와 조합하여 판단 재료로 한다면 충분히 유용한 것이다.

그리고, 단계 S99 후에는 도 20의 단계 S100으로 진행하여, 단계 S97 내지 S99에서 결과 테이블에 등록한 각 검사 결과의 내용에 의해, 통신 중인 관리대상 기기에 대한 최종적인 검사를 한다. 이 검사에 있어서는, 통신 상대가 단계 S94에서 수신한 기기 번호의 장치라고 믿어도 된다면 OK를, 그렇지 않으면 NG을 회신하도록 한다.

이 기준으로서는 예컨대, 검사 결과가 공개키 증명서와 개인키와 루트 키 증명서의 전부에 대해서 OK라면 최종 결과도 OK로 하고, 그 이외에는 NG로 하는 것을 생각할 수 있다. 그러나, 일부의 결과가 「없음」이라도 최종 결과를 OK로 하거나, OK와 NG 이외에도 관리 장치(30)의 오퍼레이터에게 경고를 발하거나 판단을 맡기거나 하는 것과 같은 검사 결과를 회신하도록 하는 것도 가능하다. 이들의 기준은 벤더에 있어서의 관리 장치(30)의 운용 기준 및 관리대상 기기(40)의 용도나 기능 등에 따라서 적절하게 정하면 된다.

또한, 단계 S94에서 정규 인증 정보를 쓸 수 없게 된 원인의 정보를 수신한 경우에는, 검사에 있어서 이러한 정보도 이용하여, 예컨대 원인에 따라서 검사의 기준을 바꾸는 것도 생각할 수 있다.

이상의 단계 S97 내지 S100의 처리가 검사 순서의 처리이며, 이 처리에 있어서, 관리 장치(30)의 CPU(11)가 검사 수단으로서 기능한다. 한편, 검사에 대해서는 단계 S97 내지 S99의 처리를 전부 행하는 것은 필수가 아니며, 최저한 이들 단계 중 어느 하나를 실행하면 된다.

다음 단계 S101에서는, 단계 S100에서의 검사 결과가 OK이었는지 여부를 판단한다. 그리고, OK라면, 단계 S102 이하의 증명서 갱신 처리를 한다.

그리고, 우선 단계 S102에서, 증명서 발행부(36)의 기능에 의해, 단계 S94에서 수신한 기기 번호를 포함하는 갱신용의 증명서를 작성한다. 도 10 등에 도시한 예에서는 공개키 증명서에는 기기 번호 이외에도 발행 대상 장치의 식별 정보를 기재하고 있는데, 이들 정보를 기재하는 경우에는, 관리 장치(30)의 데이터베이스를 참조하거나, 관리대상 기기(40)로부터 송신시키도록 하거나 하여 취득할 수 있다.

단계 S102 후에는 단계 S103으로 진행하여, 작성한 증명서의 정보를 증명서 데이터베이스에 등록한다. 이 처리에 있어서는, 예컨대 도 15 및 도 16에 도시한 것과 같은 형식의 증명서 데이터베이스를 이용하는 경우에는, 도 16에 도시한 제2 테이블에 공개키 증명서를 등록한다.

그리고, 다음 단계 S104에서는 단계 S102에서 작성한 증명서를 관리대상 기기(40)에 송신한다. 이 때, 송신한 증명서를 관리 장치(30)와의 통신에 사용하는 증명서로서 설정하도록 요구하는 증명서 설정 커맨드도 동시에 송신한다.

그리고, 단계 S105에서 증명서 설정 커맨드에 대한 응답을 기다려, 응답이 있으면 단계 S106으로 진행하여 갱신이 성공했는지의 여부를 판단한다. 그리고 성공하고 있으면, 단계 S107에서 증명서를 갱신시킨 관리대상 기기(40)에 대해서, 그 기기 번호와 대응하는 공개키 증명서의 정보를 갱신한다. 구체적으로는, 도 15에 도시한 제1 테이블에 등록해 놓은 증명서의 시리얼 번호와 발행일의 정보를, 단계 S104에서 송신한 증명서의 것으로 갱신한다. 그리고 그 후, 단계 S108에서 통신을 끊어 종료한다.

단계 S106에서 증명서의 갱신이 성공하고 있지 못한 경우에는, 그대로 통신 을 끊어 종료한다. 단계 S105에서 소정 시간 응답이 없는 경우도 마찬가지이다. 이러한 경우라도, 관리대상 기기(40) 측에서 재차 액세스해 오는 것을 생각할 수 있기 때문에, 그대로 종료해 버리더라도 지장이 없는 것이다. 이러한 경우에는, 관리대상 기기(40)는 여전히 갱신하기 전과 동일한 정규 인증 정보를 기억하고 있다고 상정되기 때문에, 도 15에 도시한 제1 테이블은 갱신하지 않도록 하고 있다.

한편, 단계 S101에서 검사 OK가 아니었던 경우에는, 단계 S109로 진행하여, 통신 상대의 관리대상 기기(40)에, 검사 불합격의 취지 및 그 이유를 기재한 메시지를 송신하고, 단계 S110에서 관리 장치(30)의 오퍼레이터에게도 검사 불합격의 취지 및 그 이유를 통지하며, 또한 단계 S108에서 통신을 끊어 종료한다. 또 이 경우, 관리대상 기기(40)에 통지를 하거나 검사 불합격의 이유를 정확하게 전하거나 하는 것이 부적절하다면, 단순히 그대로 통신을 끊거나, 더미 메시지(dummy message)를 송신하더라도 좋다.

도 1에 도시한 통신 시스템(1000)에 있어서는, 이러한 처리를 함으로써, 관리대상 기기(40)에 있어서 관리 장치(30)와의 사이에서 통상의 인증 처리에 사용하고 있었던 공개키 증명서가 인증 처리에 사용할 수 없게 되어 버린 상태라도, 또한 안전성이 비교적 낮은 공개키 증명서를 이용하여 통신 장치를 식별해야 하는 경우에 있어서도, 관리대상 기기(40)의 공개키 증명서를 갱신하여, 재차 관리 장치(30)와의 사이에서 통상의 인증 처리가 가능한 상태로 복귀시킬 수 있다.

또한, 이 경우에 있어서, 위장이 비교적 용이하게 이루어질 수 있는 레스큐 인증 정보를 이용한 비상용의 통신 경로를 사용했다고 해도, 관리대상 기기(40)가 기억하고 있는 정규 인증 정보를 기기 번호와 함께 관리 장치(30)에 송신하여, 관리 장치(30) 측에서 그 정보를 바탕으로 관리대상 기기(40)를 검사하도록 하고 있기 때문에, 상당한 확실성으로 위장을 배제하여, 부정하게 갱신용의 공개키 증명서 등을 취득되는 것을 방지할 수 있다.

또한, 정규 인증 정보에 포함되는 통상 공개키 증명서로서 공통 공개키 증명서를 사용하고 있는 경우에도 마찬가지로 그 갱신을 할 때의 위장을 배제하여, 동일한 효과를 얻을 수 있다.

또한, 이상 설명하여 온 방식에 따르면, 자동적으로 공개키 증명서를 갱신할 수 있기 때문에, 이 방식은 설치하는 곳의 조작자에 의한 증명서의 갱신을 할 수 없는 장치, 예컨대 CATV의 셋톱박스나 원격 보수의 대상이 되는 화상 형성 장치 등에 공개키 증명서를 송신할 때에 검사를 하는 검사 장치나, 그와 같은 검사 장치를 포함하는 통신 시스템에 적용하면, 특히 효과적이다.

이어서, 이상 설명하여 온 관리대상 기기(40)에 있어서의 증명서 기억부(46)의 바람직한 구성에 관해서 설명한다.

우선, 도 24에, 증명서 기억부(46)의 구성예를 도시한다.

관리대상 기기(40)에 있어서는, 도 24에 도시한 바와 같이, 증명서 기억부(46)를 구성하는 메모리로서, 상호 독립적으로 교환 가능한 제1 메모리 유닛(46a)과 제2 메모리 유닛(46b)을 설치하고, 제1 메모리 유닛(46a)에는 도 8a에 도시한 바와 같이 정규 인증 정보와 레스큐 인증 정보를 기억시키는 동시에, 제2 메모리 유닛(46b)에는 정규 인증 정보의 일부 또는 전부를 기억시키도록 하면 된다. 도 24 에 있어서는, 제2 메모리 유닛(46b)에 통상 공개키 증명서를 기억시킨 예를 나타내고 있지만, 통상 개인키나 통상 루트 키 증명서 또는 이들의 조합을 기억시키도록 하더라도 좋다. 또한, 제1 및 제2 메모리 유닛(46a, 46b)으로서는 각각 재기록 가능한 불휘발성 메모리를 이용하며, 예컨대 SRAM(Static Random Access Memory), 플래시 메모리, SD 카드나, 하드디스크 드라이브를 사용하는 것도 가능하다.

제1 메모리 유닛(46a)은, 하위 장치용 통상 공개키 증명서(75a)와 하위 장치용 통상 개인키(75b)와 상위 장치 인증용의 통상 루트 키 증명서(75c)를 포함하는 정규 인증 정보(75)와; 하위 장치용 레스큐 공개키 증명서(77a)와 하위 장치용 레스큐 개인키(77b)와 상위 장치 인증용 레스큐 루트 키 증명서(77c)를 포함한다. 제2 메모리 유닛(46b)은 하위 장치용 통상 공개키 증명서(75d)를 포함한다.

도 24에 도시한 구성에서도, 통상은 제1 메모리 유닛에 기억하고 있는 정규 인증 정보를 이용한 인증 처리를 하면 된다. 그러나, 관리대상 기기(40)의 운용 중에는 제1 메모리 유닛이 파손되어 버려 교환하지 않을 수 없게 되는 경우나, 제1 메모리 유닛을 설치한 마더보드를 고장 등에 의해 교환하지 않을 수 없게 되는 경우도 생각할 수 있다.

이러한 경우라도, 레스큐 인증 정보가 관리대상 기기(40)의 식별 정보를 포함하지 않는 것이라면, 적어도 동일 기종의 관리대상 기기(40)에 대해서는 공통의 것을 사용할 수 있으므로, 교환용의 새로운 제2 메모리 유닛(46b)을 제조할 때에 이 제2 메모리 유닛(46b)에 레스큐 인증 정보를 미리 기억시켜 두는 것이 가능하다. 그리고, 관리대상 기기(40)는 이 레스큐 인증 정보를 이용하여 관리 장치(30) 에 통신을 요구하고, 새로운 정규 인증 정보의 발행을 요구할 수 있다.

그러나, 만일 제1 메모리 유닛만이 정규 인증 정보를 기억하고 있다면, 관리대상 기기(40)로부터 제1 메모리 유닛(46a)이 제거되는 때에 관리대상 기기(40) 내에 정규 인증 정보는 없어져 버려, 새로운 정규 인증 정보의 발행을 요구될 경우에 정규 인증 정보를 관리 장치(30)에 의한 검사에 사용할 수 없게 되어 버린다. 그렇다면, 관리 장치(30)에 있어서의 검사 기준에 따라서는, 특히 안전성을 높이기 위해서 검사 결과 「없음」의 경우 검사에 합격시키지 않는 경우에는, 관리대상 기기(40)는 검사에 합격할 수 없어, 새로운 정규 인증 정보의 발행을 받을 수 없게 되어 버린다.

한편, 제2 메모리 유닛(46b)에도 정규 인증 정보를 기억시켜 놓으면, 도 25에 도시한 바와 같이, 제1 메모리 유닛(46a)을 교환한 경우라도, 제2 메모리 유닛(46b)에 기억하고 있는 정규 인증 정보는 그대로 남는다. 그리고, 이것을 관리 장치(30)에 송신하여 검사에 사용할 수 있어, 정규 인증 정보가 적절한 것이라면, 관리대상 기기(40)는 검사에 합격하여 새로운 정규 인증 정보의 발행을 받을 수 있다.

또한, 관리 장치(30)로부터 수신한 갱신용의 증명서를 제1 메모리 유닛(46a)에 기억시키는 동시에, 그 일부 또는 전부를 제2 메모리 유닛(46b)에도 기억시키도록 하면, 도 24에 도시한 원래의 상태로 복귀할 수 있다.

이와 같이, 상술한 실시예의 통신 시스템(1000)에서, 관리대상 기기(40)에 있어서, 정규 인증 정보를 구성하는 공개키 증명서와 개인키를, 독립적으로 교환할 수 있는 복수의 메모리 유닛에 분산하여 기억시키도록 하는 것이 효과적이다. 이 경우에, 공개키 증명서나 개인키를, 복수의 메모리 유닛에 기억시킬 수도 있다.

한편, 도 26에 예를 도시한 바와 같이, 하위 장치용의 통상 공개키 증명서(75d) 등은 제2 메모리 유닛(46b) 내에 정규 인증 정보(75-2)로서 기억되지만, 제1 메모리 유닛에 기억시키지 않더라도 좋다. 이 경우, 제2 메모리 유닛에 기억시킨 통상 공개키 증명서(75d) 등도 인증 처리에 사용하게 되는데, 제1 메모리 유닛(46a) 및 제2 메모리 유닛(46b)중 어느 한 쪽의 메모리 유닛을 교환한 경우라도 다른 쪽의 메모리 유닛에서 기억하고 있는 증명서 등이 남는 것은 상기한 경우와 마찬가지다. 이러한 형태도, 당연히 상기한 「분산하여」에 포함된다.

이상으로 관리대상 기기(40)의 증명서 기억부(46)에 관한 설명을 종료한다.

한편, 이러한 점 외에 다음과 같은 변경도 가능하다.

우선, 상술한 실시예에서는, 관리 장치(30)에 CA의 기능을 두어, 갱신용의 증명서를 관리 장치(30) 자신이 발행하는 예에 관해서 설명했지만, 관리 장치(30)와 CA를 따로따로의 장치로 하는 것을 방해하는 것이 아니다. 이 경우에 있어서, CA와 관리 장치(30) 사이의 통신 경로는 전용선으로 하면 좋지만, SSL이나 VPN 등에 의해 안전한 통신 경로를 확보할 수 있으면 인터넷을 통한 것이라도 좋다.

이와 같이 구성에서, 예컨대, 관리 장치(30)가 갱신용 공개키의 송신원인 피관리 기기를 검사하여 합격이라고 판단한 후, CA에 갱신용 증명서의 발행을 요구하여 갱신용 증명서를 발행시키고, CA로부터 그 갱신용 증명서를 수신하여 증명서 데이터베이스에 등록하여, 관리대상 기기(40)에 전송하도록 할 수 있다.

또한, CA에 증명서 데이터베이스를 갖게 하여, 관리 장치(30)가 검사에 사용하기 위한 공개키 증명서나 루트 키 증명서의 정보를, CA로부터 취득하도록 하더라도 좋다. CA로부터 취득하도록 하더라도, 관리대상 기기(40)와 다른 장소로부터 취득하는 것에는 변함이 없다. 이 경우에 있어서, 갱신용 증명서의 발행은 상기한 바와 같이 CA에 요구하여 행하게 할 수 있음은 물론이지만, 관리 장치(30)가 스스로 행하도록 하는 것도 가능하다.

또한, 상술한 관리 장치(30)에 있어서의 검사 기능을 CA에 포함시키더라도 좋다. 이와 같이 하는 경우에는, 관리 장치(30)는 관리대상 기기(40)로부터 검사에 사용하게 하기 위해서 수신한 기기 번호이나 정규 인증 정보 등을 CA에 전송하여, 이들을 바탕으로 CA에 검사 처리를 하여, 검사 OK이면 CA가 발행한 갱신용 증명서를, 검사 NG이면 그 취지의 정보를 취득하여 관리대상 기기(40)에 전송하게 된다. 물론, 갱신용 증명서를 취득한 경우에는 관리대상 기기(40)에 이것을 설정시킨다.

또한, 상술한 실시예에 있어서는, 관리 장치(30)가 관리대상 기기(40)를 관리하는 통신 시스템의 예에 관해서 설명했지만, 통신 상대를 검사하는 기능을 갖는 장치가, 그 검사 대상의 장치를 관리하는 것은 필수적이지 않다. 단순히 서로 통신하여 데이터의 교환을 하는 것과 같은 구성이라도 본 발명을 적용하는 것은 가능하다.

또한, 상술한 실시예에서는, 관리 장치(30)와 관리대상 기기(40)가, 도 1 또는 도 3을 이용하여 설명한 것과 같은 SSL에 따른 인증을 하는 경우의 예에 관해서 설명했다. 그러나, 이 인증이 반드시 이러한 것이 아니더라도 본 발명은 효과를 발 휘한다.

SSL을 개량한 TLS(Transport Layer Security)도 알려져 있는데, 이 프로토콜에 기초한 인증 처리를 하는 경우에도 당연히 적용 가능하다. 또한, 공개키 암호 방식에 관해서도, RSA(Rivest Shamir Adleman)뿐만 아니라, 타원 곡선 암호 등의 다른 방식의 것에도 적용 가능하다.

또한, 이상 설명한 각 변형을 적절하게 조합하여 적용할 수 있음은 물론이다.

또한, 본 발명에 의한 프로그램은, 관리 장치(30)를 제어하는 컴퓨터에, 이상 설명한 것과 같은 기능을 실현시키기 위한 프로그램이며, 이러한 프로그램을 컴퓨터에 실행시킴으로써, 상술한 바와 같은 효과를 얻을 수 있다.

이러한 프로그램은 처음부터 컴퓨터에 구비하는 ROM 또는 HDD 등의 기억 수단에 저장해 두더라도 좋지만, 기록 매체인 CD-ROM 또는 플렉시블 디스크, SRAM, EEPROM, 메모리카드 등의 불휘발성 기록 매체(메모리)에 기록하여 제공할 수도 있다. 그 메모리에 기록된 프로그램을 컴퓨터에 인스톨하여 CPU에 실행시키거나, CPU에 그 메모리로부터 이 프로그램을 독출하여 실행시킴으로써, 상술한 각 순서를 실행시킬 수 있다.

또한, 네트워크에 접속되어, 프로그램을 기록한 기록 매체를 구비하는 외부 기기 또는 프로그램을 기억 수단에 기억한 외부 기기로부터 다운로드하여 실행시키는 것도 가능하다.

이상 설명해 온 바와 같이, 본 발명의 검사 장치, 통신 시스템, 검사 방법, 프로그램 또는 기록 매체에 따르면, 안전성이 비교적 낮은 공개키 증명서를 이용하여 통신 장치를 식별해야 하는 경우에 있어서도, 위장을 효과적으로 방지할 수 있도록 할 수 있다.

따라서, 본 발명을, 각 노드가 통신을 함에 있어서 디지털 증명서를 이용한 인증 처리를 하는 식의 통신 시스템을 운용할 때에 이용함으로써, 보다 안전한 시스템을 구성할 수 있다.

도 27은 복수의 관리대상 기기가 도 4에 도시된 통신 시스템에 배열되어 있는 구성의 한 예를 도시한 도면이다. 도 27에서, 상술한 바와 같이, 관리 장치(30)는 관리 장치(30)용 레스큐 공개키 증명서(831a), 관리 장치(30)용 레스큐 개인키(831b), 및 관리대상 기기용 레스큐 루트 키 증명서(832b)를 포함한다.관리대상 기기 A(40a), 관리대상 기기 B(40b), 관리대상 기기 C(40c), 및 관리대상 기기 D(40d) 각각은 그 장치용 레스큐 공개키 증명서(731a), 그 장치용 레스큐 개인키(731b), 및 관리 장치(30) 인증용 레스큐 루트 키 증명서(732a)를 포함한다. 도 27에서, 레스큐 공개키 증명서, 레스큐 개인키, 및 레스큐 루트 키는 상술한 바와 같다.

본 발명은 특정적으로 공개된 실시예만으로 제한되는 것은 아니며, 본 발명의 사상으로부터 벗어나지 않고 변경과 수정이 가능하다.

본 출원은 2004년 7월 20일 출원된 일본 특허출원 2004-211760호와, 2005년 6월 27일 출원된 2005-187405호를 우선권으로 주장하며, 참고용으로 본 명세서에서 인용한다.

Claims (30)

1. 공개키 암호를 이용하여 인증 처리를 하는 통신 장치를 검사하기 위한 검사 장치에 있어서,

   상기 공개키 암호를 이용한 인증 처리를 하고 그 인증 처리에 사용하는 공개키 증명서를 특정한 통신 상대에게만 보내는 통신 장치로부터, 상기 통신 장치의 공개키 증명서와 상기 통신 장치의 식별 정보를 수신하는 수신 수단과;

   상기 수신 수단이 수신한 식별 정보에 대응하는 상기 공개키 증명서의 내용을 나타내는 정보를, 상기 식별 정보에 기초하여 상기 통신 장치와는 다른 장소로부터 취득하는 취득 수단과;

   상기 취득 수단이 취득한 정보를 참조하여, 상기 수신 수단이 수신한 공개키 증명서가 적절한 것인지의 여부에 기초하여 상기 통신 장치를 검사하는 검사 수단을 포함하는, 통신 장치를 검사하기 위한 검사 장치.
2. 제1항에 있어서, 상기 검사 수단은, 상기 수신 수단이 수신한 공개키 증명서의 내용과 상기 취득 수단이 취득한 정보가 일치하는지의 여부에 기초하여, 상기 공개키 증명서가 적절한 것인지의 여부를 판단하는 수단을 포함하는 것인, 통신 장치를 검사하기 위한 검사 장치.
3. 공개키 암호를 이용하여 인증 처리를 하는 통신 장치를 검사하기 위한 검사 장치에 있어서,

   공개키 암호를 이용한 인증 처리를 하는 통신 장치로부터, 상기 통신 장치의 개인키와, 상기 통신 장치의 식별 정보를 수신하는 수신 수단과;

   상기 수신 수단이 수신한 식별 정보와 대응하는 공개키를, 상기 식별 정보에 기초하여 상기 통신 장치와는 다른 장소로부터 취득하는 취득 수단과;

   상기 취득 수단이 취득한 공개키와 상기 수신 수단이 수신한 개인키가 대응하는 것인지의 여부에 기초하여, 상기 통신 장치를 검사하는 검사 수단을 포함하는, 통신 장치를 검사하기 위한 검사 장치.
4. 제3항에 있어서, 상기 통신 장치의 식별 정보와 상기 인증 처리에 사용하는 공개키와의 대응 관계를 기억하는 수단을 더 포함하는, 통신 장치를 검사하기 위한 검사 장치.
5. 제3항에 있어서, 상기 검사 수단은, 상기 취득 수단이 취득한 공개키와 상기 수신 수단이 수신한 개인키 중 한 쪽을 이용하여 주어진 데이터를 암호화하고, 다른 쪽을 이용하여 상기 암호화한 데이터를 복호화하여, 그 복호화 결과에 기초하여 상기 검사를 수행하는 수단을 포함하는 것인, 통신 장치를 검사하기 위한 검사 장치.
6. 제1항에 있어서, 상기 통신 장치가 상기 검사 수단에 의한 검사에 합격한 경우에, 상기 통신 장치에 상기 통신 장치의 새로운 공개키 증명서를 송신하는 송신 수단을 더 포함하는, 통신 장치를 검사하기 위한 검사 장치.
7. 제6항에 있어서, 상기 송신 수단이 송신하는 상기 새로운 공개키 증명서는, 상기 수신 수단이 수신한 상기 통신 장치의 식별 정보를 포함하는 공개키 증명서인 것인, 통신 장치를 검사하기 위한 검사 장치.
8. 통신 장치와 검사 장치를 포함하는 통신 시스템으로서,

   상기 통신 장치는,

   공개키 암호를 이용한 인증 처리를 하고 그 인증 처리에 사용하는 공개키 증명서를 특정한 상대에게만 보내는 인증 수단과;

   상기 통신 장치 자신의 공개키 증명서와 상기 통신 장치 자신의 식별 정보를 상기 검사 장치에 송신하는 송신 수단을 포함하고,

   상기 검사 장치는,

   상기 통신 장치의 공개키 증명서와 상기 통신 장치의 식별 정보를 수신하는 수신 수단과;

   상기 수신 수단이 수신한 식별 정보에 대응하는 공개키 증명서의 내용을 나타내는 정보를, 상기 식별 정보를 참조하여 상기 통신 장치와는 다른 장소로부터 취득하는 취득 수단과;

   상기 취득 수단이 취득한 정보를 참조하여, 상기 수신 수단이 수신한 공개키 증명서가 적절한 것인지의 여부에 기초하여 상기 통신 장치를 검사하는 검사 수단을 포함하는 것인, 통신 시스템.
9. 제8항에 있어서, 상기 검사 장치의 검사 수단은, 상기 수신 수단이 수신한 공개키 증명서의 내용과 상기 취득 수단이 취득한 정보가 일치하는지의 여부에 기초하여 상기 공개키 증명서가 적절한 것인지의 여부를 판단하는 수단을 포함하는 것인, 통신 시스템.
10. 통신 장치와 검사 장치를 포함하는 통신 시스템에 있어서,

    상기 통신 장치는,

    공개키 암호를 이용한 인증 처리를 하는 인증 수단과;

    상기 통신 장치 자신의 개인키와 상기 통신 장치 자신의 식별 정보를 상기 검사 장치에 송신하는 송신 수단을 포함하고,

    상기 검사 장치는,

    상기 통신 장치의 개인키와, 상기 통신 장치의 식별 정보를 수신하는 수신 수단과;

    상기 수신 수단이 수신한 식별 정보에 대응하는 공개키를 그 식별 정보에 기초하여 상기 통신 장치와는 다른 장소로부터 취득하는 취득 수단과;

    상기 취득 수단이 취득한 공개키와 상기 수신 수단이 수신한 개인키가 대응하는 것인지의 여부에 기초하여 상기 통신 장치를 검사하는 검사 수단을 포함하는 것인, 통신 시스템.
11. 제10항에 있어서, 상기 검사 장치는, 상기 통신 장치의 식별 정보와 상기 통신 장치가 상기 인증 처리에 사용하는 공개키와의 대응 관계를 기억하는 수단을 더 포함하는 것인, 통신 시스템.
12. 제10항에 있어서, 상기 검사 장치의 검사 수단은, 상기 취득 수단이 취득한 공개키와 상기 수신 수단이 수신한 개인키 중 한 쪽을 이용하여 주어진 데이터를 암호화하고, 다른 쪽을 이용하여 그 암호화한 데이터를 복호화하여, 그 복호화 결과에 기초하여 검사를 수행하는 수단을 포함하는 것인, 통신 시스템.
13. 제8항에 있어서, 상기 검사 장치는,

    상기 통신 장치가 상기 검사 수단에 의한 검사에 합격한 경우에, 상기 통신 장치에 상기 통신 장치의 새로운 공개키 증명서를 송신하는 송신 수단을 더 포함하며,

    상기 통신 장치는, 상기 새로운 공개키 증명서를 수신하는 수단을 더 포함하는 것인, 통신 시스템.
14. 제13항에 있어서, 상기 검사 장치의 송신 수단이 송신하는 상기 새로운 공개키 증명서는, 상기 수신 수단이 수신한 상기 통신 장치의 식별 정보를 포함하는 공개키 증명서인 것인, 통신 시스템.
15. 제8항에 있어서, 상기 통신 장치에 있어서, 상기 인증 처리에 사용하는 공개키 증명서와 개인키는, 교환 가능한 복수의 메모리 유닛에 독립적으로 기억되는 것인, 통신 시스템.
16. 공개키 암호를 이용하여 인증 처리를 하는 통신 장치를 검사하기 위한 검사 방법에 있어서,

    공개키 암호를 이용한 인증 처리를 하고 그 인증 처리에 사용하는 공개키 증명서를 특정한 상대에게 보내는 통신 장치로부터, 상기 통신 장치의 공개키 증명서와 상기 통신 장치의 식별 정보를 수신하는 수신 단계와;

    상기 수신 단계에서 수신한 식별 정보에 대응하는 공개키 증명서의 내용을 나타내는 정보를, 상기 식별 정보에 기초하여 상기 통신 장치와는 다른 장소로부터 취득하는 취득 단계와;

    상기 취득 단계에서 취득한 정보를 참조하여, 상기 수신 단계에서 수신한 공개키 증명서가 적절한 것인지의 여부에 기초하여 상기 통신 장치를 검사하는 검사 단계를 포함하는, 통신 장치를 검사하기 위한 검사 방법.
17. 제16항에 있어서, 상기 통신 장치를 검사하는 검사 단계는, 상기 수신 단계 에서 수신한 공개키 증명서의 내용과 상기 취득 단계에서 취득한 정보가 일치하는지의 여부에 기초하여, 상기 공개키 증명서가 적절한 것인지의 여부를 판단하는 단계를 포함하는 것인, 통신 장치를 검사하기 위한 검사 방법.
18. 공개키 암호를 이용하여 인증 처리를 하는 통신 장치를 검사하기 위한 검사 방법에 있어서,

    공개키 암호를 이용한 인증 처리를 하는 통신 장치로부터, 상기 통신 장치의 개인키와, 상기 통신 장치의 식별 정보를 수신하는 수신 단계와;

    상기 수신 단계에서 수신한 식별 정보와 대응하는 공개키를, 상기 통신 장치와는 다른 장소로부터 취득하는 취득 단계와;

    상기 취득 단계에서 취득한 공개키와 상기 수신 단계에서 수신한 개인키가 대응하는 것인지의 여부에 기초하여, 상기 통신 장치를 검사하는 검사 단계를 포함하는, 통신 장치를 검사하기 위한 검사 방법.
19. 제18항에 있어서, 상기 통신 장치의 식별 정보와 상기 통신 장치가 상기 인증 처리에 사용하는 공개키와의 대응 관계가, 상기 수신 단계, 상기 취득 단계, 및 상기 검사 단계를 수행하는 장치에 기억되는 것인, 통신 장치를 검사하기 위한 검사 방법.
20. 제18항에 있어서, 상기 통신 장치를 검사하는 검사 단계는, 상기 취득 단계에서 취득한 공개키와 상기 수신 단계에서 수신한 개인키 중 한 쪽을 이용하여 주어진 데이터를 암호화하고, 다른 쪽을 이용하여 그 암호화한 데이터를 복호화하여, 그 복호화 결과에 기초하여 상기 검사를 수행하는 단계를 포함하는 것인, 통신 장치를 검사하기 위한 검사 방법.
21. 제16항에 있어서, 상기 통신 장치가 상기 검사 단계에서의 검사에 합격한 경우에, 상기 통신 장치에 상기 통신 장치의 새로운 공개키 증명서를 송신하는 송신 단계를 더 포함하는, 통신 장치를 검사하기 위한 검사 방법.
22. 제21항에 있어서, 상기 송신 단계에서 송신하는 새로운 공개키 증명서는, 상기 수신 단계에서 수신한 상기 통신 장치의 식별 정보를 포함하는 공개키 증명서인 것인, 통신 장치를 검사하기 위한 검사 방법.
23. 컴퓨터로 하여금 공개키 암호를 이용하여 인증 처리를 행하도록 하는 프로그램을 기록한 컴퓨터-판독가능한 기록 매체에 있어서,

    상기 프로그램은,

    공개키 암호를 이용한 인증 처리를 하고 그 인증 처리에 사용하는 공개키 증명서를 특정한 상대에게 보내는 통신 장치로부터, 상기 통신 장치의 공개키 증명서와 상기 통신 장치의 식별 정보를 수신하는 수신 단계의 코드와;

    상기 수신 단계의 코드에서 수신한 식별 정보에 대응하는 공개키 증명서의 내용을 나타내는 정보를, 상기 식별 정보에 기초하여 상기 통신 장치와는 다른 장소로부터 취득하는 취득 단계의 코드와;

    상기 취득 단계의 코드에서 취득한 정보를 참조하여, 상기 수신 단계의 코드에서 수신한 공개키 증명서가 적절한 것인지의 여부에 기초하여 상기 통신 장치를 검사하는 검사 단계의 코드를 포함하는 것인, 컴퓨터-판독가능한 기록 매체.
24. 제23항에 있어서, 상기 통신 장치를 검사하는 검사 단계의 코드는, 상기 수신 단계의 코드가 수신한 공개키 증명서의 내용과 상기 취득 단계의 코드가 취득한 정보가 일치하는지의 여부에 기초하여, 상기 공개키 증명서가 적절한 것인지의 여부를 판단하는 코드를 포함하는 것인, 컴퓨터-판독가능한 기록 매체.
25. 컴퓨터로 하여금 공개키 암호를 이용하여 인증 처리를 행하도록 하는 프로그램을 기록한 컴퓨터-판독가능한 기록 매체에 있어서,

    상기 프로그램은,

    공개키 암호를 이용한 인증 처리를 하는 통신 장치로부터, 상기 통신 장치의 개인키와, 상기 통신 장치의 식별 정보를 수신하는 수신 단계의 코드와;

    상기 수신 단계의 코드에서 수신한 식별 정보와 대응하는 공개키를, 상기 통신 장치와는 다른 장소로부터 취득하는 취득 단계의 코드와;

    상기 취득 단계의 코드에서 취득한 공개키와 상기 수신 단계의 코드에서 수신한 개인키가 대응하는 것인지의 여부에 기초하여 상기 통신 장치를 검사하는 검사 단계의 코드를 포함하는 것인, 컴퓨터-판독가능한 기록 매체.
26. 제25항에 있어서, 상기 프로그램은, 상기 통신 장치의 식별 정보와 상기 통신 장치가 상기 인증 처리에 사용하는 공개키와의 대응 관계를 기억하는 기억 단계의 코드를 더 포함하는 것인, 컴퓨터-판독가능한 기록 매체.
27. 제25항에 있어서, 상기 통신 장치를 검사하는 검사 단계의 코드는, 상기 취득 단계의 코드에서 취득한 공개키와 상기 수신 단계의 코드에서 수신한 개인키 중 한 쪽을 이용하여 주어진 데이터를 암호화하고, 다른 쪽을 이용하여 그 암호화한 데이터를 복호화하여, 그 복호화 결과에 기초하여 검사를 수행하는 코드를 포함하는 것인, 컴퓨터-판독가능한 기록 매체.
28. 제23항에 있어서, 상기 프로그램은, 상기 통신 장치가 상기 검사 단계의 코드에 의한 검사에 합격한 경우에, 상기 통신 장치에 상기 통신 장치의 새로운 공개키 증명서를 송신하는 송신 단계의 코드를 더 포함하는 것인, 컴퓨터-판독가능한 기록 매체.
29. 제28항에 있어서, 상기 새로운 공개키 증명서를 송신하는 송신 단계의 코드에 의해 설정된 공개키 증명서는, 상기 수신 단계의 코드가 수신한 상기 통신 장치의 식별 정보를 포함하는 공개키 증명서인 것인, 컴퓨터-판독가능한 기록 매체.
30. 삭제

Images