One IT Thing

IT業界で飯を食う為の学習系雑記

security

電子署名法で求められる「本人性」と「非改ざん性」の実現方法をざっくり理解する

投稿日:2019年12月14日 更新日:

2019年現在ではマイナンバーカードが流通し始め、インターネット上で公的な申請が完了できる体制が整いつつあります。

日本は古式ゆかしい申請制度がしっかりしているのでなかなか諸外国より電子化が進みませんが、近い将来「ちょっと役所まで行ってくる」なんてこともなくなっていくはずです。

でも、転居届を出したり、家を買ったり、会社を立ち上げたりした時の公的な申請は、アマゾンで買い物をする時のオンライン注文とは重みが違いますよね。

本人が役所や会社に出向かないのにどうやって「本人による申請」であり、「申請内容が正しい」と判断すれば良いのでしょうか。

ざっくり理解して行きたいと思います。

「電子署名及び認証業務に関する法律」

オンラインで事を済ますには現実世界で行っている「割り印」や「運転免許証の提示」をインターネット上の通信で出来るようにしなければなりません。

日本では公的な申請を電子的に行う際、2001年4月1日に施行された「電子署名法」という法律に従ったシステムを作ることで、申請が完了するまでに

  1. 内容が改ざんされていない
  2. 当人からの申請だった

が電子的に証明された、と「推定」されることになっています。

第二条 この法律において「電子署名」とは、電磁的記録(電子的方式、磁気的方式その他人の知覚によっては認識することができない方式で作られる記録であって、電子計算機による情報処理の用に供されるものをいう。以下同じ。)に記録することができる情報について行われる措置であって、次の要件のいずれにも該当するものをいう。
一 当該情報が当該措置を行った者の作成に係るものであることを示すためのものであること。
二 当該情報について改変が行われていないかどうかを確認することができるものであること。

https://elaws.e-gov.go.jp/search/elawsSearch/elaws_search/lsg0500/detail?lawId=412AC0000000102

「推定」とは曖昧な表現ですが、条文にはそう書かれています。
まぁ絶対は無い、ということでしょうかね。法律家さんのごにょごにょ感を感じます。

第二章 電磁的記録の真正な成立の推定
第三条 電磁的記録であって情報を表すために作成されたもの(公務員が職務上作成したものを除く。)は、当該電磁的記録に記録された情報について本人による電子署名(これを行うために必要な符号及び物件を適正に管理することにより、本人だけが行うことができることとなるものに限る。)が行われているときは、真正に成立したものと推定する。

https://elaws.e-gov.go.jp/search/elawsSearch/elaws_search/lsg0500/detail?lawId=412AC0000000102

非改ざん性と本人性、この二つが実現出来れば、インターネットを介した公的な申請も法律で許されていることが分かりました。

では実際にシステムを開発する際にどうすれば良いか見て行きます。

1.内容が改ざんされていないかどうかのチェック方法

2者間でデータを安全にやりとりする際は「公開鍵暗号方式」を使用します。公開鍵暗号の中でもRSA暗号を使うのが一般的で、電子署名法でも推奨されています。

RSAは「公開鍵」と「秘密鍵」がペアになっていて、

  • 秘密鍵で暗号化したものは公開鍵でしか復号できない
  • 公開鍵で暗号化したものは秘密鍵でしか復号できない

ようになっている、と理解しておけば概ねOKです。

ということは申請を送信する側は

  • 申請したいデータ
  • デジタル署名値
  • 公開鍵

をセットにして提出すれば、受け取り側は

  1. 申請データのハッシュ値を計算する
  2. デジタル署名値を公開鍵で復号する(送信される前のハッシュ値に戻す)
  3. 1と2が等しいか比較する

の手順でデータが改ざんされていないことをチェック出来ることになります。

2.本人性のチェック方法

申請者Aさんを騙って悪意のある第三者が申請しようとしているかも知れません。本当にAさんが送って来たかどうか確かめるには「証明書チェーン」を検証します。

実際にICカードなどのセキュリティトークンに入っている公開鍵は「X509形式のデジタル証明書」に包まれるように入っています。

証明書には発行者の秘密鍵によって署名された証明書が連鎖しており、ルートまで遡ると信頼できるCA(Certification Authority)認証局に行き着きます。

申請データの受取側は送信されてきた証明書チェーンを逆に辿り、CA証明書が信頼して良いものであることまで分かると、このデータを送って来たのはAさんだ、と認識します。

ということは本人性まで確認するには、申請側は以下3つを送れば良いことになります。

  • 申請したいデータ
  • デジタル署名値
  • 証明書チェーン

万が一セキュリティトークンを盗まれた場合でも使用時にはパスワード(PINコード)入力が必要で、数回間違えるとロックが掛かります。この為、なりすましが出来る可能性は低いと言えます。

セキュリティトークンの入手とそれを使った開発

デジタル証明書付きのRSA鍵ペアが入っている「マイナンバーカード」や「PKCS#12形式のファイル」を手に入れられれば今まで話が実現できます。

これらを使ってコーディングする為にはPKCS#11とPKCS#12というPKI仕様を知っておく必要があります。大雑把にいうと

  • PKCS#11 : ICカードに入っている証明書付きRSA鍵ペアにアクセスする為のAPI仕様
  • PKCS#12 : 証明書付きRSA鍵ペアを電子ファイル入れる為の仕様

11の方はICカードを発行しているベンダが提供しているdllを作る為の仕様です。ICカードにアクセスする為のリーダデバイスも必要になります。

「ちょっとデータの署名値を作って検証が通るか確かめたい」くらいのケースだとPKCS#12ファイルを使った方が楽なので、次回それをやっていきたいと思います。

まとめ

  • 電子署名法に従うには本人性と非改ざん性を実現する為の仕組みが求められる。
  • 上記はRSA鍵ペアとX509証明書で実現出来る。
  • セキュリティトークンにはPKCS#11(ICカード)、PKCS#12(ファイル)がある。

オンラインで全てが事足りる時代に向けて電子署名法の改正もかなりの頻度で行われていくと思います。

現在よりもっと重要な法律になっていくでしょうから、IT屋さんがウォッチしておきたい法律の一つですね。

-security
-,

執筆者:

関連記事

ブラウザでRSA暗号化したデータをサーバで復号する(Angular + JSEncrypt、Spring MVC)【前編】

セキュリティ的にクリティカルなデータをクライアントブラウザで暗号化保存するようにしてみます。 通信経路はHTTPSで暗号化されていてもスマホに重要なデータが平文で残っていたら珠に傷です。 目次1 環境 …

CentOSで暗号鍵用のパスワードを生成

そこそこ長くて文字種の入り混じった強度の高いものを自分で考えるのは面倒です。 暗号化処理を使う際に必要なパスワード文字列を、mkpasswdコマンドでいい感じに生成出来るようにしておきます。 目次1 …

Chrome76でシークレットモード非検知を実現出来なかった件の検証

2019/07/30にChrome76がリリースされました。 76では以前からGoogleが問題視していた「閲覧者がシークレットモードでみているかどうか運営側が分かってしまう」が解決されるはずでした。 …

Javascript(暗号化JSライブラリ「Forge」)とp12ファイルで署名値を作成、Javaで検証する

前回、送信データの改ざんを検知する為、簡易的なセキュリティトークンであるPKCS#12形式のファイルを作成しました。  One IT Thing開発用のPKCS#12ファイルをOpenSSL …

開発用のRSA鍵ペア(バイナリ、テキスト)をopensslで作っておく

目次1 環境2 秘密鍵3 公開鍵4 まとめ 環境 CentOS7.6に付属のopenssl 1.0.2k。 $ cat /etc/redhat-release CentOS Linux release …

 

Shingo Nakanishi
 

東京在勤、職歴20年越え中年ITエンジニアです。まだ開発現場で頑張っています。

19歳(1996年)から書き始めた個人日記が5,000日を超え、残りの人生は発信をして行きたいと思い、令和元日からこのサイトを開始しました。勉強と試行錯誤をしながら、自分が経験したIT関連情報を投稿しています。

私と同じく、今後IT業界で生計を立てて行きたいと考えている方や、技術共有したいけどフリーランスで孤独、といった方と一緒に成長、知識共有して行けたら楽しいな、と思っています。