ＪＡＨＩＳ標準 １４－００５

JAHIS HPKI 電子認証
ガイドライン V1.1

2014 年 9 月
一般社団法人 保健医療福祉情報システム工業会
医療システム部会 セキュリティ委員会

JAHIS HPKI 電子認証ガイドライン V1.1
ま え が き本ガイドラインは保健医療福祉分野におけるヘルスケア PKI（HPKI）による認証を行うに際して、相互運用性を確保するために策定されたものである。
保健医療福祉分野においては、平成 17 年 3 月に厚生労働省により「医療情報システムの安全管理に関するガイドライン」（以下、「安全管理のガイドライン」と言う）が策定され、継続的に改定が行われている。安全管理のガイドライン」6.11 章において、相手先の識別と認証において PKI を利用出来る旨が C 項に記載されている。また、同年 4 月には、同省にて「保健医療福祉分野 PKI 認証局 証明書ポリシ」策定され、国際標準に準拠した保健医療福祉分野向けのPKI（HPKI）証明書の発行ルールが確定した。さらに平成 21 年度には厚生労働省の医療情報
ネットワーク基盤検討会において「保健医療福祉分野 PKI 認証局認証用（人）証明書ポリシ」の策定が行われた。これにより、署名用に続き、認証用についても HPKI 証明書の発行が行えることとなった。
JAHIS は、産業界の業界団体として、これら国の施策に協力するとともに、普及促進を図る
ための相互運用性の確保を図ることが重要な役割であることから、2010 年 7 月に「JAHIS
HPKI 電子認証ガイドライン V1.0」を策定し、JAHIS 標準として公開した。今般、初版策定から 3 年以上経過したことから、認証の最新動向を踏まえ、解説の追記、文言の見直しなどを行い、「JAHIS HPKI 電子認証ガイドライン V1.１」への改定を実施し、公開することとした。
本ガイドラインは、JAHIS 会員各社の意見を集約し、「JAHIS 標準」の一つとして発行したものである。したがって、会員各社がシステムの開発・更新に当たって、本ガイドラインに基づいた開発・改良を行い、本ガイドラインに準拠していることをその製品のカタログ・仕様書
等に示し、さらにその製品の使用においてユーザが理解すべき内容を説明する場合などに使われることを期待している。
また本ガイドラインは上記「安全管理のガイドライン」で示された PKI を利用した認証に関連する要求事項を、実装レベルで解説したガイドラインであり、HPKI 認証機能を利用するシステムを導入しようとしている施設が参照し利用することは歓迎するところである。ただし、当該システムが法、政令、省令、通知、ガイドラインなどに合致しているか否かの判断は、自己責任の下で自ら判断する必要があることに留意されたい。
なお、本ガイドラインで扱う HPKI 認証要件は、参照規格や技術動向にあわせて変化する可能性がある。JAHIS としても継続的に本規格のメンテナンスを重ねてゆく所存であるが、本ガイドラインの利用者はこのことにも留意されたい。
2014 年 9 月

一般社団法人 保健医療福祉情報システム工業会
セキュリティ委員会

＜＜

告知事項

＞＞

本ガイドラインは関連団体の所属の有無に関わらず、ガイドラインの引用を明示することで自由に使用することができるものとします。ただし一部の改変を伴う場合は個々の責任において行い、本規約に準拠する旨を表現することは厳禁するものとします。
本ガイドラインならびに本ガイドラインに基づいたシステムの導入・運用についてのあらゆる障害や損害について、本ガイドライン作成者は何らの責任を負わないものとしま© JAHIS 2014
す。ただし、関連団体所属の正規の資格者は本ガイドラインについての疑義を作成者に申し入れることができ、作成者はこれに誠意をもって協議するものとします。
i

目

次

１．適用範囲 .................................................................................................................................... 1
１.１
１.２

目的 ................................................................................................................................ 1
策定方針 ......................................................................................................................... 1

２．引用規格・引用文献 .................................................................................................................. 2
３．用語の定義 ................................................................................................................................ 3
４．記号および略語 ......................................................................................................................... 6
５．対象となるユースケース .......................................................................................................... 7
５.１ 医療情報ネットワーク基盤検討会で検討されたユースケース.......................................... 7
５.２ 院内で運用される医療情報システムでの加入者認証に用いるケース ............................... 7
５.３ 使ってはいけないケース .................................................................................................... 8
６．PKI 認証の概要 ......................................................................................................................... 9
６.１
６.２
６.３
６.４

PKI 認証方式の概要 ...................................................................................................... 9
対象となる機能範囲 ..................................................................................................... 10
HPKI アプリケーションの位置付け............................................................................ 12
PKI 認証と SAML ....................................................................................................... 15

７．PKI 認証機能の実装要件 ........................................................................................................ 17
７.１
７.２
７.３
７.４

一般的なアクセスコントロールのフロー .................................................................... 17
一般的な PKI による認証のフロー .............................................................................. 17
クライアントの実装要件.............................................................................................. 18
サーバの実装要件 ........................................................................................................ 19

８．HPKI におけるユーザーの識別 .............................................................................................. 21
８.１
８.２

加入者を一意に特定する情報(ID)を用いる方法.......................................................... 21
hcRole 属性を用いる方法 ............................................................................................ 21

９．署名用 HPKI と認証用 HPKI の使い分け.............................................................................. 23
９.１
９.２
９.３

使い分けの必要性 ........................................................................................................ 23
使い分けの方法 ............................................................................................................ 24
複数の EE 証明書が存在する場合の対応方法 ............................................................. 25

附属書 A HPKI 認証用証明書プロファイル（基本領域） ........................................................... 26
Ａ－１ HPKI 認証用証明書プロファイル（基本領域） ......................................................... 26
Ａ－２ HPKI 認証用証明書プロファイル（拡張領域） ......................................................... 27
付録―１．参考文献 ....................................................................................................................... 29
付録―２．作成者名簿 ................................................................................................................... 30© JAHIS 2014ii

１．適用範囲
１.１

目的
医療情報システムの利用において、主として相手先の識別と認証を目的とした HPKI による認証を確実に行うために、認証手続きについてのガイドラインを制定し、電子認証ソフトウェアなどの互換性を確
保する。

１.２

策定方針
電子認証の互換性の確保、及びなりすまし防止のために、認証に求められる署名の生成、検証及び証明書検証において最低限行わねばならないことについて明確に定める。
また検証では医療分野特有の検証要件として、HPKI のポリシへの準拠性を確認できることが必要であることを明確に定める。これにより証明書内に記載された国家資格等の識別を活用することができる。
ユースケースを想定し、ユースケースに応じた利用方法を提示する。
認証のフレームワークについての規定は行わないが、一般的な利用方法として想定される、SSL クラ
イアント認証ならびに独自のクライアント機能による認証を例にした実装要件を提示する。

© JAHIS 20141

２．引用規格・引用文献
個人が自らの医療情報を管理・活用する基盤を構築する際に必要となる医療従事者の認証方式について
http://www.mhlw.go.jp/shingi/2009/02/dl/s0213-8e.pdf
保健医療福祉分野 PKI 認証局認証用（人）証明書ポリシ 1.1 版（平成２２年３月）

http://www.mhlw.go.jp/seisakunitsuite/bunya/kenkou_iryou/iryou/johoka/pki-policy/2203_02.html
HPKI 対応 IC カードガイドライン 第 2 版 http://www.jahis.jp/10-002/© JAHIS 20142

３．用語の定義
アサーション
特定のユーザが認証済みであることや、その属性情報等を主張するためのメッセージ。
SAML によるサイト間の連携は、他のサイトが発行したアサーションを信用することにより成立する。
アプリケーション
特定の目的を果たすための機能を提供するソフトウェア。
インターフェース
プログラムや装置、操作者といった対象の間で情報のやりとりを仲介するもの。また、その規格。
改ざん
情報を管理者の許可を得ずに書き換える行為。
加入者
加入者とは、証明書所有者である。証明書所有者とは、証明書発行申請を行い認証局により証明書を発行される個人、機器、施設等をさす。証明書所有者の範囲は次のとおりとする。
・ 保健医療福祉分野サービスの提供者及び利用者
・ 上記の提供者の内、以下の者がその有する資格において、あるいは管理者として認証を行う場
合は、「その資格を有していること」あるいは「管理者であること」を証明書に記載しなくてはならない。
・ 保健医療福祉分野に関わる国家資格を有する者
・ 医療機関等の管理者(「保健医療福祉分野 PKI 認証局認証用（人）証明書ポリシ」（厚生労働省））
公開鍵証明書加入者の名義と公開鍵を結合して公開鍵の真正性を証明する証明書で、印鑑証明書に相当する。電子証明書あるいは単に証明書ともいう。公開鍵証明書には、公開鍵の加入者情報、公開鍵、CA の情報、その他証明書の利用規則等が記載され、CA の署名が付される。
(「保健医療福祉分野 PKI 認証局 認証用（人）証明書ポリシ」（厚生労働省））失効
有効期限前に、何らかの理由（盗難・紛失など）により電子証明書を無効にすること。基本的には、本人からの申告によるが、緊急時には CA の判断で失効されることもある。
(「保健医療福祉分野 PKI 認証局認証用（人）証明書ポリシ」（厚生労働省））
失効情報
公開鍵証明書の有効性を確認できるよう、認証局から開示される情報。無効になった証明書のシリア
ル番号等をリストアップした失効リスト（CRL: Certification Revocation List）や、オンラインでの証明書有効性の確認要求に対し応答を返す OCSP レスポンダ（OCSP: Online Certificate Status
Protocol）があるが、CRL を採用している認証局が一般的。また、認証局は通常、証明書の有効期限を越えて失効情報を開示していない。
私有鍵
公開鍵と対になる鍵。公開せず、他人に漏れないように鍵の所有者だけが管理する。私有鍵で署名したものは、それに対応する公開鍵でのみ検証が可能である。
(「保健医療福祉分野 PKI 認証局認証用（人）証明書ポリシ」（厚生労働省））© JAHIS 20143

証明書ポリシ(CP: Certificate Policy)
共通のセキュリティ要件を満たし、特定のコミュニティ及び／又はアプリケーションのクラスへの適用性を指定する、名前付けされた規定の集合。
(「保健医療福祉分野 PKI 認証局認証用（人）証明書ポリシ」（厚生労働省））
署名検証
電子署名が正当なものか確認する行為。以下のように証明書検証と署名値の検証から構成される。
（証
明書検証：証明書の正当性、有効性の検証）① 署名に用いた証明書が正当な認証局から発行されたものであること② 検証時に証明書の有効期間が切れていないこと③ 失効していない有効な証明書で有ること（署名値の検証：署名対象データが改ざんされていないかどうかの検証）④ 署名対象文書のハッシュ値と署名データから得られるハッシュ値が等しいこと
デバイス
コンピュータに搭載あるいは接続されるハードウェア。
電子署名
電子文書の正当性を保証するために付けられる署名情報。公開鍵暗号などを利用し、相手が本人であることを確認するとともに、情報が送信途中に改ざんされていないことを証明することができる。公
開鍵暗号方式を用いて生成した署名はデジタル署名ともいう。
(「保健医療福祉分野 PKI 認証局認証用（人）証明書ポリシ」（厚生労働省））電子認証
電子的に「特定の名前のもとで何かを申請したり、何かにアクセスしようとしたりする個人もしくは組織体が、実際に正当な個人もしくは組織体であること」を確立する過程のこと。
登録局(RA: Registration Authority)
登録局は、適切な申請者の本人確認、登録の業務を行い、発行局への証明書発行要求を行う。なお、証明書登録の業務は、発行、失効を含む。
但し、登録局は認証局の運営主体で定める CPS の遵守及び個人情報の厳正な取り扱いを条件に、契約を取り交わすことで業務の一部を外部に委託することができる。
(「保健医療福祉分野 PKI 認証局認証用（人）証明書ポリシ」（厚生労働省））
トラストアンカ
認証パスにおいて、信用の基点となる証明書（ルート証明書など）のこと。
認証局(CA: Certification Authority)
電子証明書を発行する機関。認証局は、公開鍵が間違いなく本人のものであると証明可能にする第三者機関で、公正、中立な立場にあり信頼できなければならない。
(「保健医療福祉分野 PKI 認証局認証用（人）証明書ポリシ」（厚生労働省））認証パス(Certification Path)
トラストアンカ（信頼点）となる CA から検証対象である証明書までを結ぶ一連の証明書の繋がり。
ライブラリ
ある機能を提供するプログラム部品群。単体では動作せずソフトウェアの一部として組み込まれることで機能する。

© JAHIS 2014
4

PKCS#11
米 RSA Security 社が定めた公開鍵暗号技術をベースとした規格群である PKCS (PublicKey
Cryptography Standards)の内、暗号トークンに関するインターフェース標準。
AID
IC カード内のアプリケーション識別子© JAHIS 20145

４．記号および略語
このガイドラインでは、次の記号および略語／表記を用いる。
PKI

Public Key Infrastructure
公開鍵基盤。公開鍵暗号化方式という暗号技術を基に認証局が公開鍵証明書を発行し、この証明書を用いて署名／署名検証、暗号／復号、認証を可能にする仕組み。
(「保健医療福祉分野 PKI 認証局認証用（人）証明書ポリシ（厚生労働省））

HPKI

HealthCare PKI
保健医療福祉分野での公開鍵基盤。

CSP

Cryptographic Service Provider
Microsoft 社による暗号化のためのソフトウェアコンポーネント。

ISOInternational Organization for Standardization
電気分野を除く工業分野の国際的な標準規格を策定するための団体。

OID

Object Identifier
オブジェクト識別子。オブジェクトの識別を行うため、オブジェクトに関連付けられた一意な値。
(「保健医療福祉分野 PKI 認証局認証用（人）証明書ポリシ（厚生労働省））

SSL

Secure Socket Layer
HTTP や FTP などの上位のプロトコルで送受信されるデータを暗号化して送受信するプロトコル

CA

Certificate Authority
認証局（認証機関）。証明書を発行し管理する機関。

EE

End Entity
CA 以外の証明書が発行される主体。

CRL

Certification Revocation List
認証局が発行する証明書失効リスト。

SSO

Single Sign-On
一度の認証によって複数のサービス等が利用可能になる認証機能

RADIUS

Remote Authentication Dial-In User Service
認証と接続記録をネットワーク上のサーバにて一元化する IP 上のプロトコル。

© JAHIS 20146

５．対象となるユースケース
認証用 HPKI を利用することで以下のメリットがある。
① 医療分野での利用を目的とした証明書ポリシが一元的に定められ、相互運用性が確保されている。
② 証明書内に記載される hcRole 属性 により国家資格等の属性認証が行える。
③ 医療分野で広く利用できる外部の医療認証基盤システム 1 のサービスが利用可能である。
本章では、上記に挙げたメリットが有効なユースケースを検討する。
５.１ 医療情報ネットワーク基盤検討会で検討されたユースケース
厚生労働省の医療情報ネットワーク基盤検討会では作業班を設けて、個人自らの健康情報の管理・活用の視点から想定されるユースケースを洗い出し、医療の現場を見据えた議論が行われてきている。そこで提出された成果報告書に下記のような３つのユースケースが示されている。
①かかりつけの医師が、患者の医療・健康情報を患者の同意のもと参照する場合②かかりつけの医師ではないが、医療機関を受診した患者の医療・健康情報を患者の同意のもと、もしくは緊急に参照する場合③医療専門職が旅先などでたまたま居合わせた急病人に対しケアをする際に、患者の同意のもと、もしくは緊急に患者の医療・健康情報を参照する場合
これらのユースケースでは、いずれも患者の医療・健康情報にアクセスし、参照しなければならない
が、医療情報を含む健康情報は機微な個人情報であるため、許可された者のみが参照する仕組みが必要である。また、緊急時、特に本人の意識が清明でない場合においては救命活動を優先して行う必要があるため、本人同意を経由しない何らかの緊急時の情報参照の仕組みが必要となる。このような本人同意なしに情報を参照する場合、少なくとも医療の専門家（国家資格保有者）であることが担保されていなくてはならない。更に、医療分野においては、特定の医療専門職のみにしか許されていない医療行為がある。このことから、どの医療専門職であるかどうかを判別することは非常に重要である。また、ユースケースによっては、医療専門職ごとにアクセスできる権限が異なることが想定されるため、ユースケースごとのアクセス条件に応じたアクセス権の付与を行う仕組みが必要になる。このように医療専門職の資格という属性を判断し、アクセスを許可する仕組み（属性認証）を実現する方策のひとつとして HPKI 認証が有効である。
５.２ 院内で運用される医療情報システムでの加入者認証に用いるケース
認証用 HPKI が構築された場合には、５.１で想定したユースケース以外にも、地域連携や院内の病院情報システムなどにおける認証に活用が検討されることも想定される。例えば、地域連携システムにおける認証・認可に利用することや、医療機関の病院情報システムの認証・認可に利用するなどが考えられる。その場合、地域や院内で配布する認証用のカード等を、認証用 HPKI 認証局 から発行されるHPKI カードで代用でき、情報システム構築コストを低減できる可能性がある。ただし、認証用 HPKI が提供するフレームワークのみでは、加入者の本人性、実在性、および医療専門職としての国家資格の有無しか担保できないため、実際の運用には不十分である。従って、認証用 HPKI 証明書では本人性、実在性、国家資格の確認のみに限定されるので、地域連携や院内システムにおける国家資格以外の属性を含めた認証要件については、システム側で適切な管理・運営を実施しなくてはならない。また、認証用
HPKI のフレームワークを利用する際に生じるリスク（認証局が保証する保証範囲を超えた利用を行う
場合の責任のあり方等）などについて分析を行い、必要な運用管理規定や認証ルールを追加構築する必1 医療認証基盤システムとは平成 22 年度に経済産業省が実施した「医療情報化促進事業」に「医療分野認証

基盤整備コンソーシアム」が構築した医療分野で共通に利用できるシングル・サインオンの仕組みである。
日本医師会では本システムを「日本医師会医療認証基盤」として継続して運用している。
（http://www.jmaca.med.or.jp/role/certification_base.html）© JAHIS 20147

要がある。
さらに、特に院内システムで認証用 HPKI のフレームワークを利用する場合には、施設のセキュリティポリシーに依存して外部のネットワーク接続が制限されることにより、医療認証基盤システムなどの外部の認証システムと連携できない場合も想定される。また、外部ネットワークが接続可能の場合でも、医療認証基盤システムなどにも利用される SSL 認証フレームワークを使用する場合にはネットワークの性能と可用性の課題、IC カードを用いた場合にはアクセス速度、IC カード内 PKI アプリケーション処
理速度の限界等の各種応答性を考慮する必要がある。特に高い可用性・応答性能が要求される電子カル
テ等の稼動条件に対しては認証の仕組みについて要権を満たすよう設計して実装する必要がある。一方、地域連携システムにおいて複数のサービス事業者によるサービス連携を行うケースや他の地域連携シス
テムとの連携を行う場合には、標準的な SSO の仕組みが必須となる。この場合、オープンで標準的な外部の認証システムとして医療認証基盤システムの利用が推奨される。
５.３ 使ってはいけないケース
・加入者本人が証明書の安全性を担保する必要があるため、共有機器に複数名の私有鍵をインストール
するのは推奨しない。
・共有機器を利用する場合には、加入者本人のみが所有し利用可能なトークン（IC カード等）に私有鍵および証明書を格納すべきである。
・HPKI カード等から HPKI 認証用証明書を読み出してそれだけで加入者を特定することは可能であるが、認証としては利用できない。

© JAHIS 2014
8

６．PKI 認証の概要
PKI 認証方式の概要
PKI 認証とは、認証用の私有鍵と公開鍵証明書により電子認証を行う仕組みのことである。
私有鍵による署名を検証することにより本人性を確認し、公開鍵証明書の検証によって実在性を確認することで証明書所有者を認証することが出来る。なお、証明書所有者には人に限らず機器、組織となる場合があるが、本ガイドラインでは人が証明書所有者であることを前提に説明する。
PKI 認証を実装する場合の方法には様々な方式があるが、次に主な方式について概要を示す。

６.１

６.１.１ SSL クライアント認証
HTTPS で始まる URL にアクセスすることで SSL ハンドシェイクプロトコルにより、サーバからク
ライアントに対し証明書と署名データを求め、その証明書と署名データを検証して正当なクライアントからの接続要求であることを確認して接続を確立する WEB サイトの認証方式である。クライアントではサーバに送る証明書を選択する操作が必要になり、不特定多数が利用するクライアントでは選択が容易に行える工夫が必要となる。
認証の操作は HTTPS のセッション開始時およびセッションタイムアウト後の再接続の度に求められる。
６.１.２ ActiveX 等による独自のクライアント認証
WEB アプリケーションにおいて、
業務アプリケーションの任意のタイミングで加入者認証を行う場合には、ブラウザに Microsoft 社の Internet Explorer を用いる場合を例にすると、独自のクライアント認証機能を ActiveX 技術で実装する方式がある。
独自のクライアント認証機能は IC カード等で私有鍵による署名データを生成し、これをサーバに送信する。サーバ側では送信された署名データを検証機能にて署名検証と証明書の検証を行い加入者を認証する。
６.１.３ クライアントローカルアプリケーションでの認証
クライアントアプリケーションが単独で IC カード等による加入者認証（加入者識別）を行う場合は、
IC カード等に格納された私有鍵による署名を生成して、その署名検証及び証明書検証を行って加入者を認証する。

© JAHIS 2014
9

６.２

対象となる機能範囲
本ガイドラインの対象となる機能範囲は、業務アプリケーションに実装されるユーザのログイン認証
機能おいて、
IC カード等に格納された認証用 HPKI 秘密鍵と証明書を用いた PKI 認証を実行する HPKI
アプリケーション機能である。
業務アプリケーションの形態には WEB アプリケーション形式とクライアントアプリケーション形式に大別される６.２.１ WEB アプリケーション形式の構成（１）SSL クライアント認証
Web ブラウザ
SSL 処理CSP または
PKCS#11

Web サーバ
SSL 処理業務アプリケーション

IC カード

図 6.2.1

SSL クライアント認証

WEB アプリケーションにおける HPKI アプリケーション層にあたる署名と検証処理部分は SSL 処理に該当する。

（２）ActiveX によるＰＫＩ認証
Web ブラウザ

Web サーバ

HPKI

業務アプリケーション
HPKI アプリケ

アプリケーションーション（ActiveX）

IC カード

図 6.2.2 ActiveX によるＰＫＩ認証

クライアントの HPKI アプリケーション（ActiveX）にて署名を行い、サーバの HPKI アプリケーシ
ョンにて署名の検証を行う。

© JAHIS 201410

６.２.２ クライアントアプリケーションの形式の構成（１）アプリケーション内部に組み込むＰＫＩ認証
クライアント
業務アプリケーション
HPKI
アプリケーション

IC カード

図 6.2.3 クライアントアプリケーション
クライアントの HPKI アプリケーションにて署名と署名の検証を行う。

© JAHIS 201411

６.３ HPKI アプリケーションの位置付け
６.３.１ WEB アプリケーション形式の位置付け
WEB アプリケーションの場合は、クライアントモジュールとサーバモジュールに HPKI アプリケー
ション層が存在する。
WEB サーバ
業務アプリケーション層

HPKI アプリケーション層（サーバ）

クライアント（WEB ブラウザ等）
HPKI アプリケーション層（クライアント）
CSP、ActiveX 等
PKI ミドルウェア層（PKCS#11, Crypto API 等）
カードエッジインターフェース

PC/SC 等デバイス（USB 等）

IC カード RW
IC カード

図 6.3.1

WEB アプリケーションの構成© JAHIS 201412

（１） SSL クライアント認証
WEB ブラウザによる SSL クライアント認証の場合、クライアントでの HPKI アプリケーション層に該当する部分は、WEB ブラウザの SSL 処理機能と、IC カード等の秘密鍵を用いた署名処理のために用意される CSP モジュールである。
一方、サーバでは WEB サーバ機能にて SSL ハンドシェイクにてクライアントの証明書の検証が行われた後に HTTPS 通信が行われる。WEB サーバから取得する加入者の HPKI 証明書を解析して、加入者を識別し業務アプリケーション層にて権限等による認可処理を行う。HPKI アプリケーション層は
WEB サーバ内の SSL 処理系部分と HPKI 証明書を解析部分が該当する。
（２） ActiveX 等の独自認証
SSL クライアント認証を用いず、独自処理で IC カード等を用いて認証を行う場合はクライアントでは ActiveX 等のクライアントモジュールを用意する。この ActiveX 等が HPKI アプリケーション層の位置付けとなる。
一方、サーバでは ActiveX 等のクライアントモジュールで署名されたデータを WEB サーバに送付しサーバ側で署名検証処理を行う部分が HPKI アプリケーション層となる。

© JAHIS 201413

６.３.２
クライアントアプリケーションの位置付け
クライアントアプリケーションでは、IC カード等を用いて認証を行う部分が HPKI アプリケーション
層の位置付けとなる。

クライアントアプリケーション
HPKI アプリケーション層

PKI ミドルウェア層（PKCS#11, Crypto API 等）
カードエッジインターフェース

PC/SC 等デバイス（USB 等）

IC カード RW
IC カード

図 6.3.2

クライアントアプリケーションの構成© JAHIS 2014
14

PKI 認証と SAML
SAML（Security Assertion Markup Language）等の認証連携のフレームワークを用いることで、ア
プリケーションから認証の機能を独立させることができる。SAML の仕組みは固有の認証方法には依存していないため、様々な認証方法を採用することができる。PKI による加入者の認証を行う場合には、
認証オーソリティが加入者の証明書を検証する。

６.４

PKI を使用した事例については日本医師会が認証サーバを構築・運用しているので、経済産業省「平成 22 年度サービス産業活動環境整備調査事業（医療等情報化共通基盤構築調査事業）」の成果報告書 2 、3
添付資料：SAML 実装仕様書 を参照されたい。
図 6.4.1 は、SAML により認証を行う Web アプリケーションの一例である。

⑥認証アサーションの検証とサービス提供の認可④加入者の認証アサーション要求

アプリケーション
認証
サーバ⑤認証アサーション発行 オーソリティ①サービス要求②認証オーソリティへ転送③加入者の認証

ブラウザ(例) 加入者の証明書

加入者

図 6.4.1 SAML による WEB アプリケーションの一例
SAML では認証オーソリティが加入者の認証を行い、その結果を含めた認証アサーションを発行する。
アプリケーションは認証オーソリティから認証アサーションを取得することにより、加入者の本人性を確認することができる。
図 6.4.2 のように認証オーソリティ以外に、加入者の属性情報を提供する属性オーソリティや、認可を行う認可決定オーソリティがある。
この仕組みを利用することでシングルサインオンや、異なるドメイン間の ID 連携を実現することができる。
なお、図 6.4.2 は「JAHIS シングルサインオン実装ガイド」4 からの抜粋に加筆したものである。

2

22 年度サービス産業活動環境整備調査事業（医療等情報化共通基盤構築調査事業）」の成果報告書（http://www.keieiken.co.jp/medit/pdf/240423/7-report.pdf）
3 SAML 実装仕様書（http://www.keieiken.co.jp/medit/pdf/240423/7-data.pdf）
4 「JAHIS シングルサインオン実装ガイド」（http://www.jahis.jp/wp/wp-content/uploads/SSOguide-document(1).pdf）© JAHIS 201415

外部認証環境
PKIなど

認証要求

属性DBなど（Role)

アクセス規制など（Rule)

PolicyPolicyPolicy認証オーソリティ

属性オーソリティ

認可決定オーソリティ

属性アサーション

認可決定
アサーション

SAML
認証アサーション

加入者サービス要求サービス提供者

図 6.4.2 SAML による認証
認証オーソリティは認証アサーションに署名をして発行するが、この署名に使用する証明書について
は本ガイドラインの対象外である。
認証連携のフレームワークを用いる場合には各オーソリティとそれを利用するアプリケーションやサービス提供者との間の信頼関係が必要である。適用する認証方法、情報提供の範囲や仕組み、運用方法などについての合意を形成することが求められる。

© JAHIS 2014
16

７．PKI 認証機能の実装要件
７.１ 一般的なアクセスコントロールのフロー
アクセスコントロールの機能をもつ一般的なアプリケーションは加入者に対して以下の処理を行う。
(1) 加入者の識別
加入者が誰であるかを特定する。証明書に記載された本人識別情報を元に加入者を特定する。
(2) 加入者の認証
加入者の身元が正しい者であることを確認する。PKI による認証の場合には加入者の署名と証明書を検証することで加入者の身元の正しさを確認する。一般的な PKI による認証のフローを 7.2 節で述べる。
又、SAML を使用し認証を行う場合は、他の標準（JAHIS シングルサインオン実装ガイドなど）を参照のこと。

(3) 加入者に対する認可
加入者にアプリケーションの操作や情報へのアクセスに対する認可を与える。加入者の ID（もしくは所属するグループ）に対して定義されたアクセスコントロールリストを元に認可を行う場合や、加入者の属性情報（例えば hcRole 属性や SAML のアサーションなど）に対応づけられた操作権限により認可を行う場合などがある。
加入者の識別や認可の実装方法はアプリケーションに依存している。
この章では PKI による認証機能に対して認証プロトコルに依存しない共通の実装要件を述べる。
７.２

一般的な PKI による認証のフロー

ここでは PKI による加入者の認証方法の代表的な例として署名を用いた認証処理のフローを述べる。

クライアント

加入者②署名済み認証用情報を送信

サーバ④加入者の証明書を検証
私有鍵

認証用情報

①認証用情報に署名

加入者の証明書③認証用情報の署名を検証

図 7.2.1 署名を用いた一般的な認証処理のフロー

認証処理は主に以下のような流れになる。
① クライアントが認証用情報に対して私有鍵で署名する。
認証用情報とはサーバが加入者を認証するために使用する情報で認証プロトコルにより異なる。例えば、サーバクライアントの間で共有している情報から認証用情報が生成される場合や、サーバがクライアントに対して発行した乱数（チャレンジ）を用いる場合などがある。一般的に、このような認証用情報は認証プロトコル内で完結するため加入者が直接知ることは無く、クライアントによって処理が行われる。クライアントは認証用情報への署名を行うために、加入者に対して認証用の私有鍵に対する PIN 入力を促す。
② クライアントは加入者の署名済み認証用情報をサーバへ送信する。このとき、加入者の証明書や検証に必要な中間認証局の証明書をサーバへ送信することもある。

© JAHIS 201417

③ サーバはクライアントから送られてきた署名済み認証用情報の署名を検証する。サーバは、サーバが保持している（もしくは算出した）認証用情報と加入者の証明書から取得した公開鍵を用いて、加入者の署名を検証する。
④ サーバは加入者の証明書を検証し、加入者の身元の正しさを確認する。加入者の証明書から信頼の起点となる認証局の証明書（トラストアンカ）までのパスが有効であることを検証する。
認証用情報の処理に関しては認証プロトコルの規格に従い実装することが求められる。加入者の署名や証明書の扱いに関しては PKI による認証機能に共通のものとして次節以降の要件を満たす必要がある。
７.３

クライアントの実装要件

クライアントの実装における実装要件を以下に示す。
表 7.3.1 クライアントの実装要件
要求レベル

項目名

内容

説明

オプション

私有鍵選択時の鍵使

私有鍵を使用する前に、私有鍵

署名用の私有鍵を誤用しないように、安用目的の確認に対応する証明書の鍵使用目

全のため、認証用途のものであることを的が認証用の鍵使用目的と適確認したうえで使用することを強く推奨

合することを確認する。

する。

私有鍵選択時の証明

私有鍵を使用する前に、私有鍵サーバでの認証を受ける前に、クライア書の有効性確認に対応する証明書のパス検証

ント側で有効な証明書であることを確認を行い、トラストアンカまでのする。クライアント側での検証処理の負パス構築、有効期限や失効状態

荷を考慮して、実装の有無を選択できる。

オプションなどを確認する。

© JAHIS 2014
18

７.４

サーバの実装要件

サーバの実装における実装要件を以下に示す。
表 7.4.1 サーバの実装要件
要求レベル

項目

内容

説明

必須

トラストアンカの適

トラストアンカとして厚生労働加入者の証明書を検証するには、トラス切な設定と管理

省 HPKI ルート認証局が設定でトアンカの設定が必須である。トラスト

きること。

アンカの設定が不適切な場合には、意図

トラストアンカの設定を安全にしない不正な証明書を受け入れてしまう

管理すること。

危険性があるため、トラストアンカに対する適切な設定と安全な管理が必要である。

必須

加入者の公開鍵を用

加入者の公開鍵を用いて、クラ加入者の署名、加入者の証明書から取得いた署名の検証

イアントから送られてきた加入

した公開鍵、サーバが保持している（も者の署名を検証すること。

しくは算出した）認証用情報を用いて、署名値が正しいことを確認する。
公開鍵による署名の検証を行うことにより、署名がその公開鍵と対となる私有鍵
によって生成されたことを確認すること
ができる。

必須

加入者の証明書の認加入者の証明書からトラストア

トラストアンカまでの認証パス上にある証パスの有効性確認ンカとなる厚生労働省 HPKI ル

証明書の有効性を検証することで、加入

ート認証局までの認証パスを検者の身元の正しさを確認する。

証できること。
検証方法は RFC5280 のパス検証に従う。
代表的な検証項目として以下のものがある。
加入者からトラストアンカ

証明書に記載されている発行者名と、そまでのパス構築の発行者となる認証局証明書の主体者名が一致するパスを構築する。トラストアンカとなる厚生労働省 HPKI ルート認証
局まで到達するパスを構築する。

証明書に付与された認証局

認証パス上の証明書に対して、証明書をの署名の検証

発行している認証局の署名がついていることを確認する。証明書の署名を認証局
証明書の公開鍵で検証する。

認証局証明書の CA フラグの認証パス上の認証局証明書について、証確認

明書の基本制約フィールドに CA フラグがあることを確認する。CA フラグがない場合には、認証局としての業務を認められない者（例えばエンドユーザ）が証明書を発行していることになるため、認証局証明書として受け入れてはならない。

© JAHIS 201419

証明書ポリシの確認

認証パス上の証明書に対して、証明書ポ
リシの OID が HPKI 認証用証明書ポリシと適合することを確認する。

証明書の鍵使用目的の確認

加入者の証明書の鍵使用目的が認証用の鍵使用目的と適合することを確認する。

認証パス上の証明書の有効

認証パス上の証明書について、現在時刻

期限確認において証明書の有効期限が切れていないことを確認する。

認証パス上の証明書の失効

認証パス上の証明書について、現在時刻

確認において証明書が失効されていないことを確認する。

失効情報に付された署名の失効情報に付された署名が、正しい認証

検証

局により付されたものであることを確認
する。

オプション

hcRole 属性の取得

加入者の証明書から hcRole 属

hcRole によるアクセスコントロールを性を取得する。

行う場合など、アプリケーションの要件に応じて実装する。

証明書ポリシの確認

証明書ポリシの確認

認証パス上の証明書に対して、証明書ポ
リシの OID が HPKI 認証用証明書ポリシと適合することを確認する。

© JAHIS 201420

８．HPKI におけるユーザーの識別システムやアプリケーションは HPKI 認証用証明書に記載された情報に基づいて加入者に与えられた権限を確認することで、システムやアプリケーション、データ等へのアクセスに対する認可を行うことができる。アクセスに対する認可のための権限の付与方法には、加入者を一意に特定する情報(ID)を用いる方法と、加入者の hcRole 属性を用いる方法、また、両者を勘案したうえで権限を付与する方法がある。ID に基づいて権限を付与する方法と hcRole 属性に基づいて権限を付与する方法を以下の節で記述する。なお、HPKI 認証用証明書のプロファイルについては、附属書 A を参照されたい。
８.１ 加入者を一意に特定する情報(ID)を用いる方法
HPKI 認証用証明書には、証明書に記載される加入者名(Subject) として、加入者の氏名(CommonName)が含まれており、さらに、シリアル番号(SN)を含めることができるとされている。この
シリアル番号に医籍登録番号、薬剤師名簿番号等の一意に割り振られた番号が含まれている場合には、認証局によらず一意に識別できるため、加入者の ID として使用することができる。それ以外の場合には、
SN を含んだ Subject の識別名と、認証局の名称(Issuer)により、加入者を一意に識別することができる。
この SN は証明書の SerialNumber のフィールドとは異なるため注意が必要である。SerialNumber は同一の認証局が発行する証明書で一意となる番号を付与するものであり、同一の加入者であっても再発行された証明書では異なる番号が割り当てられる。
ID と権限の対応づけはシステムやアプリケーションで行うが、その具体的な方法は本規格のスコープ外である。ID と権限の対応付けの例としては以下のものがあげられる。
a) HPKI 認証用証明書から取得した ID に対して直接権限を対応づける方法
b)HPKI 認証用証明書から取得した ID に対応づけられたシステム内で管理する ID（例えば、システム固有のユーザ ID やグループ ID など）に対して権限を対応付ける方法c) HPKI 認証用証明書から取得した ID に対してシステム内で管理された加入者の役割もしくは属性に対して権限を対応付ける方法
８.２ hcRole 属性を用いる方法
HPKI 認証用証明書には、ISO 17090 で規定される hcRole 属性が記載される。この hcRole 属性には
表 8.2.1 に示す国家資格や医療機関の管理責任者の資格情報が含まれる。
システムまたはアプリケーションは HPKI 認証用証明書より加入者の hcRole 属性を取得し、hcRole
属性が示す資格情報に対応付けられた権限を確認することでアクセスに対する認可を行うことができる。
hcRole 属性に基づくアクセスに対する認可は、加入者を一意に特定することなく実行することができる
ため、緊急時における医師資格を持つ加入者による参照等の利用場面に適用できる。これは HPKI 認証
用証明書の特長のひとつである。

資格名（国家資格）‘Medical Doctor’‘Dentist’‘Pharmacist’‘Medical Technologist’‘Radiological Technologist’‘General Nurse’‘Public Health Nurse’‘Midwife’© JAHIS 201421

表 8.2.1 HPKI 資格名テーブル
説明
医師
歯科医師
薬剤師
臨床検査技師
診療放射線技師
看護師
保健師
助産師

理学療法士‘Physical Therapist’
作業療法士‘Occupational Therapist’
視能訓練士‘Orthoptist’
言語聴覚士‘Speech Therapist’
歯科技工士‘Dental Technician’
管理栄養士‘National Registered ‘Dietitian’
社会福祉士‘Certified Social Worker’
介護福祉士‘Certified Care Worker’
救急救命士‘Emergency Medical Technician’
精神保健福祉士
‘Psychiatric Social Worker’
臨床工学技師‘Clinical Engineer’
あん摩マッサージ指圧師/はり師/きゅう師‘Masseur’
歯科衛生士‘Dental Hygienist’
義肢装具士‘Prosthetics & Orthctic’
柔道整復師‘Artificial Limb Fitter’
衛生検査技師‘Clinical Laboratory Technician’
資格名（医療機関の管理責任者）
説明
病院長‘Director of Hospital’診療所院長‘Director of Clinic’
管理薬剤師‘Supervisor of Pharmacy’
薬局開設者‘Proprietor of Pharmacy’
その他の保健医療福祉機関の管理責任者‘Director’
注）資格名のワード間の空白は一個の Space (x20)となる。
「保健医療福祉分野 PKI 認証局認証用（人）証明書ポリシ」（厚生労働省）より© JAHIS 201422

９．署名用 HPKI と認証用 HPKI の使い分け
１枚の HPKI 用 IC カード内に署名用の鍵（私有鍵）と認証用の鍵（私有鍵）とが共存する場合がある。本章では、署名用の鍵と認証用の鍵を区別して使い分けることの必要性と HPKI における両者の使い分けの方法について述べる。
９.１

使い分けの必要性

PKI は、秘匿（親展）、認証（ログイン時等の本人認証）、署名（電子署名）に用いられる。これらのうち認証と署名は私有鍵による暗号化処理、つまり署名値の生成処理を基本とする 5。
認証と署名では基本的な処理は同等（署名値の生成処理を基本とするという意味で）であるが、署名値の生成者（つまり私有鍵の保持者）にとって結果として生じる意味的な効果は大きく異なる。認証の場合、署名値の生成者に対する効果はサービスの利用が許可されるか拒絶されるかであるが、署名の場
合は、署名値の生成者は署名した対象文書の内容に依存した責務を負うことになる場合がある。署名用の鍵を認証用に使用することに伴うリスクを次に説明する。
PKI による認証においては、チャレンジ＆レスポンス方式が用いられる場合が多い。単純なチャレン
ジ＆レスポンス方式では、認証主体が生成したチャレンジ（乱数）を対象に被認証者側のクライアント
ソフトが署名値を生成・送付し、それを認証主体が検証するといった手順が用いられる（図 9.1.1）。
認証要求

クライアント（被認証者）

サーバ（認証主体）

チャレンジ（乱数）
乱数に署名
署名[乱数]、証明書

証明書・署名検証

署名値

OK ならば許可
図 9.1.1 単純なチャレンジ＆レスポンス方式による認証手順
このような方式では、認証主体側が有意な文書のハッシュ値をチャンレンジとして送付したとしても被認証者側ではそのことを認識することは不可能であるため、被認証者側では通常の処理に従ってそのハッシュ値に対して署名値を生成し送り返すことになる。このとき、認証主体側では元の文書と受け取った署名値とを組み合わせることによって容易に被認証者が署名したと見做せる文書を生成することができる。例えば借用書のハッシュ値をチャレンジとして用いた場合、被認証者は意図せず借用書に署名をしてしまい、その結果金銭を要求されるというリスクにさらされることになる（図 9.1.2）。

5 SSH での公開鍵暗号によるユーザ認証方式のように親展（公開鍵による暗号化処理）に基づく認証方式もあるが、この方式は本章で述べるようなリスクを伴わないため、ここでは言及しないこととする。
© JAHIS 201423

クライアント（被認証者）

認証要求

サーバ（認証主体）

ﾁｬﾚﾝｼﾞ（ﾊｯｼｭ値）
乱数に署名

署名[乱数]、証明書
署名文書を根拠に返済を請求

ハッシュ値

借用書

署名値
署名文書と同じ形式を生成

図 9.1.2 意図せぬ電子署名の生成
このリスクへの対策として、署名用の鍵と認証用の鍵の区別をそれぞれの公開鍵証明書の証明書ポ
リシ、鍵使用目的などに明記しておくことが効果的である。これらの情報に基づいて署名用の鍵を認証に用いないようにしたり、あるいは認証用の鍵で意図せぬ電子署名付き文書が作成されたとしても、ポリシによってその電子署名を無効とみなすようにすることが可能となる。
上記のようなリスク回避の観点の他、求められる暗号アルゴリズムあるいはそのパラメータの強度の違いから両者を使い分けることが有効である場合が考えられる。認証の場合、署名値の検証は認証主体
によって認証時のみに行えばよいが、電子署名の場合は対象文書の保存期間にわたって署名値を検証できる必要がある場合がある。従って、認証用のアルゴリズムおよびパラメータよりも署名用のアルゴリ
ズムおよびパラメータにより高い強度が求められる。例えば RSA 暗号を用いる場合、より高い強度を要求される署名用の鍵長を 2048 ビットとし、認証用の鍵長を 1024 ビットとするなどの使い分けが考え
られる。
９.２

使い分けの方法

HPKI 対応 IC カードガイドラインによると、認証用 HPKI カードアプリケーションと署名用 HPKI
カードアプリケーションが規定され、それぞれ別々の IC カードアプリケーション識別子（AID）が割り当てられる。
１枚の IC カードには、認証用 HPKI カードアプリケーション、または署名用 HPKI カードアプリケ
ーションのいずれか一つのカードアプリケーションしか存在しない場合と、それぞれ１つずつで２つのカードアプリケーションが存在する場合が想定されている。また、それぞれのカードアプリケーション
内には、私有鍵とそれに対応するエンドエンティティ（EE）公開鍵証明書は一つずつしか存在しないことが想定されている。
HPKI 対応の PKCS#11 ライブラリは、認証用 HPKI と署名用 HPKI のそれぞれに対して異なる dll
等として実装することがHPKI 対応IC カードガイドラインで推奨されている。それぞれの PKCS#11 ラ
イブラリには対応するカードアプリケーションの AID が保持されているため、PKCS#11 ライブラリの利用者が AID を意識する必要はない。認証用 HPKI 対応 PKCS#11 ライブラリと署名用 HPKI 対応
PKCS#11 ライブラリはファイル名で区別する(例えば、認証用：HpkiAuthP11.dll、署名用：
HpkiSigP11.dll)。
Crypto API の場合も同様で、電子署名用の CSP と認証用の CSP がそれぞれを用意することが推奨されている。両者はプロバイダ名で区別され、例えばそれぞれ"HPKI Crypto Service Provider for Non
Repudiation"、"HPKI Crypto Service Provider for Authentication"となる。やはりこの場合も Crypto© JAHIS 201424

API の利用者が AID を意識する必要はない。
HPKI アプリケーションは、認証用 HPKI を利用するか署名用 HPKI を利用するかを意識して実装する必要がある。HPKI アプリケーションが認証用 HPKI カードアプリケーションにアクセスする場合は、認証用 HPKI 対応 PKCS#11 ライブラリ（上記例では HpkiAuthP11.dll）をロードして利用する。また、
HPKI アプリケーションが署名用 HPKI カードアプリケーションにアクセスする場合は、署名用 HPKI
対応 PKCS#11 ライブラリ（上記例では HpkiSigP11.dll）をロードして利用する。
Crypto API の場合、プロバイダハンドルを得るときに署名用であるか認証用であるかの用途に応じた
プロバイダを上記のプロバイダ名で指定する。
なお、PKCS#11 および Crypto API のインターフェースとコーリングシーケンスの詳細についてはHPKI 対応 IC カードガイドラインの最新版を参照されたい。
９.３

複数の EE 証明書が存在する場合の対応方法

HPKI 対応 IC カードガイドラインでは、１枚の IC カードには、認証用 HPKI カードアプリケーショ
ンおよび署名用 HPKI カードアプリケーションがそれぞれ一つまでしか存在しないことが想定されており、またそれぞれのカードアプリケーション内には、私有鍵とそれに対応する EE 証明書は一つずつしか存在しないことが想定されている。また、認証用 HPKI を利用するか署名用 HPKI を利用するかによって HPKI アプリケーションは PKCS#11 ライブラリあるいは CSP を使い分けるため、常に HPKI アプ
リケーションには利用できる証明書（と対応する私有鍵）は高々一つしか見えない。従って、HPKI 対応
IC カードガイドラインが推奨するIC カードを利用するのであれば、複数のEE 証明書が存在する場合の対応方法を考慮する必要はない。
一方、HPKI 対応 IC カードガイドラインの推奨に従っておらず利用できる EE 証明書を複数格納する
IC カードを利用する場合、鍵を利用するにあたり、まずクライアント側で候補となる EE 証明書を取得
し、各証明書について、トラストアンカ、証明書ポリシ、鍵使用目的、サブジェクト、有効期間、失効状態などをチェックし、利用する私有鍵を選択するという手順を必要とするかもしれない。ただし、認証の場合は証明書検証を厳密に行う必要があるのは加入者を受け入れるサーバ側であり、クライアント
側では証明書にかかわる処理を必要最低限として応答性能を重視しようという考え方もある。9.1 でも述
べたとおり、署名の場合と比較して、認証の場合はクライアント側で誤った証明書（と私有鍵）を利用した場合のリスクが少ないと考えられるからである。ただし、やはり9.1で述べた署名用の鍵を認証に用いた場合のリスクを考えると鍵使用目的のみは確実にチェックするように実装することを強く推奨する。

© JAHIS 201425

附属書 A HPKI 認証用証明書プロファイル（基本領域）
Ａ－１ HPKI 認証用証明書プロファイル（基本領域）
表 A.1 HPKI 認証用証明書プロファイル（基本領域）
項目

設定

説明

Version◎Ｖer3 とする。

SerialNumber◎

同一認証局が発行する証明書内でユニークな値とする。

Signature◎

Validity◎

NotBefore◎

NotAfter◎◎

英数字のみ使用する。（CountryName は Printable、それ以
外は UTF-8 で記述する）

CountryName◎

c=JP（固定）とする。

LocalityName△

OrganizationName◎

OrganizationUnitName△

Issuer◎

認証局のポリシを示す文字列を記載する。
（「HPKI-01-*-forAuthentication-forIndividual」とする。
なお、文字列中の"01"は、CP の版数である"第 1.0 版"を示す。
また、"*"は CA を唯一に識別できる文字列とする。）◎

英数字のみ使用する。（CountryName、SerialNumber はPrintable、それ以外は UTF-8 で記述する）

CountryName◎

c=JP（固定）とする。

LocalityName△

OrganizationName○

OrganizationUnitName○

CommonName◎

GivenName×

SurName×

e-Mail×

SerialNumber△

CommonName

Subject© JAHIS 201426

加入者が医療機関等の管理者の場合は必須。
その場合は医療福祉機関名をローマ字あるいは英語名でOrganizationName に記載し、OrganizatioUnitName に”
Director”の文字列を格納する。
加入者の氏名をローマ字で記載する。

医籍登録番号などを記載することができる。

SubjectPublicKeyInfo◎

Algorithm◎

SubjectPublicKey◎

IssuerUniqueID×SubjectUniqueID×

Extentions◎

RSAEncryption とする。

拡張領域（Extensions）参照

表中の、「◎」は必須、「○」は場合により必須、「△」はオプション、「×」は設定しないことを表している。
「保健医療福祉分野 PKI 認証局認証用（人）証明書ポリシ」（厚生労働省）より

Ａ－２ HPKI 認証用証明書プロファイル（拡張領域）
表 A.2 HPKI 認証用証明書プロファイル（拡張領域）
項目

設定

説明

CriticalauthorityKeyIdentifier

◎

FALSE

subejctKeyIdentifier

◎

FALSE

KeyUsage◎

TRUE

DigitalSignature◎-

NonRepudiation

×-KeyEncipherment

×-

DataEncipherment

×-

KeyAgreement

×-

KeyCertSign

×-CRLSign×-

EncipherOnly

×-

DeciphermentOnly

×-

extendedKeyUsage

△

FALSE

privateKeyUsagePeriod

×

FALSE

certificatePolicies

◎

TRUE

policyMapping

×

FALSE

subjectAltName

△

FALSE

issuerAltName

△

FALSE

subjectDirectoryAttributes◎

医療従事者等の資格（hcRole）を記載。

AttrType○

加入者が国家資格保有者及び医療機関等の管理者の場合は必須。その他(患者等)の場合は省略可。

-

AttrValues○

HCActor の codeDataFreeText に資格名テーブルの英表記を UTF8String で設定。subject が複数の資格を有する場合は、HCActorData に資格
数分の HCActor を設定する。

-© JAHIS 2014
27

FALSE

basicConstraints

×

TRUE

CA

×

-

pathLenConstraints

×-

nameConstraints

×

TRUE

policyConstraints

×

TRUE

cRLDistributionPoints◎

subjectInfoAccess

×

FALSE

authorityInfoAccess

△

FALSE

DirectoryName あるいは URI で、CRL の配布点を指定する。

FALSE

表中の、「◎」は必須、「○」は場合により必須、「△」はオプション、「×」は設定しないことを表している。
「保健医療福祉分野 PKI 認証局認証用（人）証明書ポリシ」（厚生労働省）より© JAHIS 201428

付録―１．参考文献
厚生労働省・医療情報システムの安全管理に関するガイドライン 第４．２版
http://www.mhlw.go.jp/stf/shingi/0000026088.html
独立行政法人 情報処理推進機構(IPA)・PKI 関連技術解説
http://www.ipa.go.jp/security/pki/
JAHIS・ヘルスケア PKI を利用した医療文書に対する電子署名規格 V1.1
http://www.jahis.jp/jahis_standards_healthcarepk_12-007/
ISO 17090-1:2008
Health informatics -- Public key infrastructure -- Part 1: Overview of digital certificate services
ISO 17090-2:2008
Health informatics -- Public key infrastructure -- Part 2: Certificate profile
ISO 17090-3:2008
Health informatics - Public key infrastructure - Part 3: Policy management of certification authority© JAHIS 201429

付録―２．作成者名簿作成者（社名五十音順）（株）グッドマン
サイバートラスト（株）
シーメンス・ジャパン（株）
ＪＡＨＩＳ特別委員（株）島津製作所
セコム（株）
セコム（株）
東芝住電医療情報システムズ（株）
日本光電工業（株）
日本光電工業（株）
日本電気（株）
富士通（株）
三菱電機インフォメーションシステムズ（株）
三菱電機（株）
三菱電機（株）© JAHIS 2014
30

下野 兼輝
松本 義和
平田 泰三
長谷川 英重
西田 慎一郎
佐藤 雅史
西山 晃
岡田 康
佐藤 恵一
別府 嗣信
高野 敏男
熊野 顕生
瀧 勝也
宮崎 一哉
茗原 秀幸

日付
2010/03
2014/09

バージョン
V1.0
V1.1

改定履歴
内容
初版
全体 文言の見直しを実施
はじめに 改定に伴う変更を実施
３章 アサーション、トラストアンカを追記
５章 解説を追記
６章 図 6.4.2 追加ならびにその解説を追加
７章 SAML に関する記述を追加
表 7.4.1 サーバ実装要件の「証明書ポリシの確認」を必須からオプションに変更
８章 解説の簡素化
表 8.2.1 看護師の資格名を”General Nurse”に修正（ＪＡＨＩＳ標準 １４－００５）
２０１４年９月発行
ＪＡＨＩＳ HPKI 電子認証ガイドラインＶ１．１
発行元 一般社団法人 保健医療福祉情報システム工業会〒１０５－０００４ 東京都港区新橋２丁目５番５号（新橋２丁目ＭＴビル５階）
電話 03-3506-8010

FAX 03-3506-8070（無断複写・転載を禁ず）© JAHIS 201431