マイナンバーのチェックデジットは仕様上入力ミスを検知できない場合がある 77
ストーリー by hylom
なんとまあ 部門より
なんとまあ 部門より
マイナンバーでは入力間違いがあった場合にそれを検出できるよう、マイナンバーの最下位(一番右側の1桁) が「チェックデジット」に割り当てられている。チェックデジットの一般的な実装では、ナンバーの各桁を特定の数式で処理することで入力されたナンバーが間違っていないかどうかを検出できるのだが、マイナンバーのチェックデジットでは実装の仕様上、入力ミスの仕方によってはそれを検出できないのだという(デジタル・フォレンジック研究会の第404号コラム「マイナンバーのチェックデジットについて」)。
たとえばチェックデジットが0の場合、1桁の入力ミスのうち約9.1%を検出できないという。さらに法人番号については「0」と「9」を取り違えた場合、間違いを検出できないという。
チェックディジットは気安め (スコア:5, 興味深い)
正直なところ、わたしはそもそも1桁のチェックディジットすら
あまり必要性を感じないです。このマイナンバーに関しては。
というのも、マイナンバーに似たようなアメリカの「社会保障番号」が
チェックディジットを持ってません。
https://ja.wikipedia.org/wiki/%E7%A4%BE%E4%BC%9A%E4%BF%9D%E9%9A%9C%E7%... [wikipedia.org]
そして、そもそもマイナンバーって異なる個人情報間の
ひもづけのためのキーなので、名前や生年月日など個々のデータが個別に持っている
他の属性値で"正しいリンクキーか"をある程度はチェック可能です。
手書き数字をシステムに入力するときも、まあ大抵の入力フォーマットには
名前とか住所とかを合わせて書く仕様になってますよね。
もちろん偶然の一致は有り得ますが、たかだか1桁or2桁のチェックディジットが
1/10あるいは1/100の偶然を防げないことと比べたら統計的には十分安全と言えます。
クレカIDとかライセンスシリアルとかはそれ自体が単体でキーとなりうるものなので
チェックディジットは必須ですが、マイナンバーは単体では意味がないものです。
(少なくとも私の理解では)
ゆえに番号それ自体のチェック機構は限り無く不要に近い、ということですね。
Re:チェックディジットは気安め (スコア:1)
「12桁の数字」がマイナンバーか否かを判定する材料になるので、必要。
具体的には、メールゲートウェイやプロキシで、「12桁の数字」をアップロードしようとしたら、
その数字のチェックデジットを確認し、マイナンバーの可能性があればブロックする、という
運用が可能。(そういう機能を持つ機器が既にいくつも存在する)
入力誤りの検知目的としては、そこまで重要ではないんだろうけど。
Re: (スコア:0)
運用上、連番を順繰りに附番していくケースではチェックデジットが有効だと思うけれど、
連番を避けるような運用を前提とするならあんまり意味ないと思うんだよね。
そういう前後の番号が参照されることを避ける附番を行うシステムにしているなら、
番号単独での個体照合・突合なんてのはまず行われないし。
Re: (スコア:0)
つまり必要もないもののために入力量を10%も増加させてると。
検知できない場合が「高い」のが問題でしょう (スコア:3)
入力ミスを検知できない場合が「ある」。有るか無いかだと、あって当たり前ですが。
ここでの問題は1桁の入力誤りを 検知できない率が「高い」点だと思います。
デジタル・フォレンジック研究会 の文章によるとマイナンバーの設計では
「この見逃しは検査用数字が0の時のみ発生しますので、
この場合に限ると実に1桁誤りの約9.1%を検出することが出来ません。」とのこと。
数字のケタをケチらずチェックデジット2ケタで設計しても良かったと思いますけど。
なおオマケで懐かしネタ1980年代のマイコン誌と16進数ダンプリストとチェックサムの記事。
「にがMSX OCRとMSXを利用してオールドPCのダンプリストを入力する」 [sytes.net]
トレードオフを無視してないかな (スコア:3, 興味深い)
そりゃチェックディジットの桁数を増やせば検出率は上がりますが、そんなのは自明で指摘するまでもないことでは。
桁数や文字種を増やせば入力効率は当然低下するわけで、そこにはトレードオフがあります。
マイナンバーを11桁から12桁に増やすということは、9.1%もの入力量増加になるわけで、それについて考慮しなくてよいのでしょうか?
1桁の誤入力の場合の検出率が特定のケースで91.9%だからというだけの理由で現行の方法を批判するのが、公平な意見とは思えません。
元記事はVerhoeff algorithmというマイナーなアルゴリズムを使うと、1桁の数字のみのチェックディジットでも
よい検出率を実現できるという紹介で、主眼はこちらではないでしょうか(私が見た時点では、コメントで誰一人言及していないようですが)。
Re:トレードオフを無視してないかな (スコア:2)
1ケタ増えて数字キーを叩く余分な労働は多分1秒か2秒。
1ケタ増やさないで別の人間が登録された場合は、
「本人に携帯電話で連絡」とか「書類作成やり直し」で余計な労働は30分(翌日持ち越しもあり)。
別人登録の確率が9%ならこれは無視できないですよ。
Re:トレードオフを無視してないかな (スコア:2)
やや! 計算すると「1件当たりの余計な労働は0.33秒」ですか。恐れ入りました。
Re:トレードオフを無視してないかな (スコア:2)
とても攻撃的なコメントをありがとう。敵意がよく伝わってきます。匿名って本当に便利ですね。
Re:トレードオフを無視してないかな (スコア:1)
桁数の問題ではなく仕様の問題だと思います。
数字10文字しか使用しないのにモジュラス11を採用しており、11種類の計算結果を10種類に丸めています。
例えばJAN13のチェックデジットは1桁ですが、モジュラス10を採用しており1桁の入力ミスを100%検出します。
Re: (スコア:0)
それもあるけどよりによって間違えやすい0と9だからなぁ。
Re:検知できない場合が「高い」のが問題でしょう (スコア:3, おもしろおかしい)
アラビア数字なんか使わずに漢数字にすれば良かったのに
Re: (スコア:0)
やめてください漢数字で入力を強制するWebフォームに疲れ果てて死んでしまいます
Re:検知できない場合が「高い」のが問題でしょう (スコア:2)
こういうの入力する場合はテンキーを使うでしょう。
無刻印HHKを使ってる? 0と9を打ち間違えるようじゃ修行が足りんでしょう。:-)
Re: (スコア:0)
打ち間違いじゃなくて見間違いの話でしょう。字体によると思うけど。
#手書きだと79が(たまに4も)怪しい
Re: (スコア:0)
0と9を間違えやすい字体ってあんまり見かけないかな。
6と8と9を判別しづらいケースの方が圧倒的に多い。
あとは斜線付きの0と8。
手書きのときは2と7と1とか、4と9とか、3と5で識別しづらい字を書く人が結構いる。
Re: (スコア:0)
最近 ノートPCも多いから、そもそもテンキーない環境もあるんじゃないかな。
無限の猿定理 (スコア:2)
無限の猿定理
https://ja.wikipedia.org/wiki/%E7%84%A1%E9%99%90%E3%81%AE%E7%8C%BF%E5%... [wikipedia.org]
思ったんだけど (スコア:0)
チェックデジットをアルファベットにしたらいいだけではないの?
Re: (スコア:0)
間違えても通ってしまうのが問題なんだからアルファベットにしたところで意味はないだろう
マイナンバーのSHAを入力してもらえばいい
入力ミスしても通ることはまずない
Re:思ったんだけど (スコア:5, 参考になる)
ちゃんとリンク先を読め、で終わる話なんですが説明しとくと、個人用マイナンバーと法人用マイナンバーでは全然別のチェックデジット付加方法を採用してますが、
個人用マイナンバーは、mod 11 なので、チェックデジットに11種類の文字が必要ですが、それを数字で表現するために、余り0も余り10もチェックデジットを割り当ててます。その結果、チェックデジットが0の場合は、「余り0が余り10になったり、余り10が余り0になるような誤りは、チェックデジットが0のまま変わらない」から誤り検出できないので、誤り検出率が落ちるという問題があります。
法人用マイナンバーは、mod 9 を使って、チェックデジットは1~9の9種類(最上位桁にチェックデジットを配置しているので、0を避けたかったのだろうと推測されてます)。mod 9 では、「0 も 9 も、どちらも余り0」なために、mod には分配則が成り立つことを考慮してないような計算式のマズさにより、「各桁の数値が0から9になったり、9から0になっても、チェックデジットは変わらない」という問題があるのです。
どちらも「チェックデジットを無理矢理数字一桁で表現しよう」としているためにダメになっちゃった例ですので、アルファベットにするというのも一種の解決策です。
リンク先の記事では「大学入試センター試験の受験番号や試験場コードでは、「11で割った」結果を11種のアルファベットで表す」といった例も挙げられてますし、ISBNの旧形式(10桁)なんかもチェックデジットは0~9とXの11種類です。
まあ、そこまでしなくても、最初から「数字一桁でも問題のない方法」を採用すればいいだけですけどね。JANコードで使ってるチェックデジット経緯算式は、今回の法人用番号とほぼ簡単同じ式ですが、mod 10 で、今回のネタのような問題はありませんし。
Re: (スコア:0)
不思議なんですが、そういう問題があることが明らかなのになんでチェックサムの計算方式ではmod 9やmod 11が主流なんでしょうか。かつてのrand関数みたいに特に理由もなく昔から使われているものが使われているだけなんでしょうか。
Re:思ったんだけど (スコア:3, 興味深い)
mod 11 には、全然問題はありません。mod 11 では11種類のチェックデジットが発生するので、数字1桁で表現できない、というデメリットがあるだけ。
それを、余り10も余り0もチェックデジットを0にする、という個人用マイナンバーのアルゴリズムが腐ってるんです。
「桁の入れ替わりを検出するため、個々の桁に固有の定数をかける」場合、その定数とモジュロが互いに素である事が重要です。例えば、mod 10 で、ある桁の数値に2をかけると、その桁では0(×2=0)と5(×2=10)のチェックデジットが一致することになってしまいます。
11は素数なので、「互いに素となるような数を多く作り出せる」という点でメリットがあります。
法人用マイナンバーの mod 9 は、まー論外ですね。そんな方法を使ってるとこはどこにもありません。主流でもなんでもないです。
JANコードと法人マイナンバーのアルゴリズムはよく似ていて、
JANコード: mod 10、奇数桁は×1、偶数桁は×3
法人用マイナンバー: mod 9、奇数桁は×1、偶数桁は×2
という違いしかありません。
おそらく、JANコード(mod 10)のアルゴリズムをベースに、「0は避けたいのでチェックデジットは9種類にしたい」「9種類にするならmod 9だ」「mod 9 だと、×3はダメだから、偶数桁は×2にしとこう」という安直な考え方で作られたんじゃないかと思ってしまいます。
Re:思ったんだけど (スコア:2)
とりあえず、ECCを付けて、入出力を機械任せにしてみてはどうだろうか。
Re:思ったんだけど (スコア:1)
>>「0」と「9」を取り違えた場合、間違いを検出できないという。
まずこのリンクを読んでから書き込みして欲しい。
Re: (スコア:0)
高々12桁の10進数字に、最低でも20バイト必要なSHA [wikipedia.org]を使うとか全然意味ないだろ。
検知できない場合がある (スコア:0)
はい?なんのためのチェックデジットなんだろか、、、
Re: (スコア:0)
必ず検知できるんだったら、単なる冗長化やん
Re:検知できない場合がある (スコア:3, 興味深い)
> こうしてみると、結局のところOCR(パスポートの場合)、バーコード(牛個体番号)、マークシート(大学入試センター)といった光学的な機械読み取りが前提となっているコードにはチェックデジットが抵抗なく、かつ比較的「正しく」導入されてきたのに、事務処理上機械入力されることが前提になっておらず、人による手入力が前提になっている運転免許証などのコードにはチェックデジットが導入されないか、導入されるとしても深く考えられていないものが用いられている傾向が感じられます。
元記事は「確実に検知できないからゴミ」と言いたいわけではないらしい
書類仕事が自動化される時には暗号学の素養が必要なアルゴリズム選択が雑になりがちということを嘆いているんだろうか
Re:検知できない場合がある (スコア:1)
つまり、事務処理で用いられるコードに対してどのようなチェックデジットを与えるのが適切かという判断基準がなく、それが(人手の作業も含む)事務処理上の効率化において鍵になるという発想が共有されていないのが問題だろうと思うのです。
...
それと同様に、チェックデジットに限らずICT機器と人が連携して事務処理を行う際に、技術的な勘所に対して何らかの基準を満たすことを促すような仕組みが、国の機関のどこかに必要な気がするのです。
雑なのを嘆くとともに、そもそも必要性が認識されてない事も言いたいようだ。
思うに、人が介在するシステムの問題は、介在する人にも責任が分散してしまうから解決が後手になるんだと思う。なにごとにつけ。
Re:検知できない場合がある (スコア:1)
実装によって若干の差はあるが、チェックデジットが1桁なら「入力ミスでも1/10に近い確率で通ることはある」
いやまあ、たとえば「各桁の数字を足して下1桁をチェックディジットにする」みたいな原始的な方法なら「1桁の入力ミス」は確実に検知できるけど
今度は「12345678」と「12354678」みたいな間違いを検知できない
チェックディジットは単純に「誤入力の確率を減らす」だけで「誤入力を確実に検知できる」ものではないんだよなぁ
確実に検知したけりゃ親コメの言うように冗長化するしかない
Re: (スコア:0)
これ読んでいないよね。
分かりやすくするため、個人番号を11桁の数字abcdefghijkxとしますと、
検査用数字xはx = 11 – (6a + 5b + 4c + 3d + 2e + 7f + 6g + 5h + 4i + 3j + 2k) mod 11 ただしx≧10ならx=0です。
これなら、まだしもわかりやすいでしょうか。
Re: (スコア:0)
その分かりやすい説明で何がわかったと思ってるのか
わかんないなぁ
Re:検知できない場合がある (スコア:5, 参考になる)
まあ確かに、あのコメントで意味が分かるような人は、#3052845 [srad.jp]みたいなボケたことは最初っから書かないでしょうね。、
#3052873 [srad.jp]の式が意味することは、「隣り合う桁に対して、異なる数を乗する」ことで、「隣り合う数値が入れ替わった時にはチェックデジットが変わる」ようになっているってことです。
> 今度は「12345678」と「12354678」みたいな間違いを検知できない
なんていう浅はかなチェックデジットなんて今時使ってるとこなんてありません。
ちなみに、製品バーコードとして広く使われているJANコードなんかは、「(a+3b+c+3d+e+…+k+3l+m) mod 10 = 0」を満たすようにチェックデジットmが設計されてます。こうすることで、隣り合う数字の入れ替わりは検出できます。
(たとえば、コードの始まり2桁が「12」だったら、この部分のチェックデジット計算用の数値は1+3×2=7になりますが、この2桁が入れ替わって「21」になったらチェックデジット計算用の数値は2+3×1=5で、元の数値と変わるので誤り検出できます)
ですが、この式だと二つ隣の入れ替わり(12345678が12543678になるなど)は検出できません。
それでも、「各桁の数値を間違える」「隣り合う数値が入れ替わる」という「人間がやってしまいがちな入力ミス」に対抗するには、こういう式でも十分効果があると考えられており、これが実用に供されているわけです。
Re: (スコア:0)
チェックデジットが数字1桁である以上、全部合わせれば確率10%で通ってしまうのは避けようがないけど、人間がやりがちな間違いに検知率を偏らせるように工夫がされてるってことですよね。平均すればデータ量の増加は避けようがないからといって可逆圧縮が不可能ではないように。
# しかし#3052845のようなボケたコメントがプラスモデされるのが今のスラドクォリティ
Re: (スコア:0)
1桁の入力ミスを検知できないことがあるチェックデジットなんてゴミでしょ
CDが0の人は挙手 (スコア:0)
ソースで軽く触れてますが、
仕様として決めてはいるけどそもそも割り振ってないってこともあるのでは。
Re:CDが0の人は挙手 (スコア:1)
私のチェックデジットは0でした。ということで、普通に割り振ってあるようですよ。
Re: (スコア:0)
正確には、「計算して本来10であるべきだけど0が割り振られた人」が居るかどうかですね。
そういうケースに該当してるかわかりますか?
Re:CDが0の人は挙手 (スコア:1)
私はまさにそのケースです。
番号のうち見間違えそうな数を変化させた1桁誤りのうち、3パターンで誤り検出に失敗することも確認しています。
晒し上げよう (スコア:0)
どこの誰がそういう仕様にした(仕様を作った)んでしょうか
晒し上げない駄目でしょ
Re: (スコア:0)
リンク先に書いてあるよ。
こいつはよくあるチェックデジットです。
気休めなんで、べつに実用上は問題ないんじゃないの?
まじめに作るならエラーはホワイトなのかとかも
気になってきますね。リンク先で紹介されてるのは
そのへんも少しは考慮されていると思います。
入れ替えとか言ってるので、多分。
実用的なところを気にするなら、どんなエラーを救いたいのか、
ホワイトとするとBERはどれくらいが目標なのか、
だいたい符号化率に大きな制約があるわけじゃないだろうとか、
気になってきます。
で、リンク先のもだけど、故意になんかした場合の強度とかは
考えてないでしょう?
これはあくまで入力間違いチェックの第一関門ですよ。
出てきた名前見ればわかるじゃん。
背景がわかった (スコア:0)
>>こうしてみると、結局のところOCR(パスポートの場合)、バーコード(牛個体番号)、マークシート(大学入試センター)といった光学的な機械読み取りが前提となっているコードにはチェックデジットが抵抗なく、かつ比較的「正しく」導入されてきたのに、事務処理上機械入力されることが前提になっておらず、人による手入力が前提になっている運転免許証などのコードにはチェックデジットが導入されないか、導入されるとしても深く考えられていないものが用いられている傾向が感じられます。
要するに手入力する時にテンキーだけ使って入力したいからそうしたんだろうね。
かなり鋭い意見だね。
チェックデジットはエラーを発見する為にあるからそこを悪くしたら駄目なんだよね。
そうならそうと言えば、ちゃんとしたまともな人が対案を出してくれるはずなのに自分達の意見が正しいからパブリックコメントは見ないとかやっているからこうなる。
チェックデジットをアルファベットにしても問題ないでしょ。
例えば入力画面で11桁+2桁入力(アルファベット)って2桁を打ってアルファベットに変換するだけでいいんだし。
なんでこんな簡単な事をやるのに不具合がでるようなシステムにしているんだろうね。
Re:背景がわかった (スコア:1)
とことん分かってないだろ。
Re: (スコア:0)
http://srad.jp/comment/3052889 [srad.jp]
ここに書いたけど、別の言い方だと、人のせいに出来てしまう逃げ道が用意されてるから、対処しなければならないという圧力が弱いので。
桁数ずれとかは? (スコア:0)
個人番号同士、法人番号同士の誤り検出能力も重要ですが、これらの桁数が違うことから
・個人番号12桁の入力時に1桁打ち過ぎて、法人番号と重なる
・法人番号13桁の入力時に1桁打ち飛ばして、個人番号と重なる
というケースはどうなんでしょう。
(代数的には当然一致するコードはあるけど、付番の仕方から事実上問題ないこともあり得るのでよく分からん)
Re: (スコア:0)
個人番号と法人番号は用途が異なると思うので、どちらを入れても良い場合ってのがそもそもあるのかどうかと、もしあるなら別途どちらかを指定させれば済む話じゃないか?
Re: (スコア:0)
法人と個人の取り違えはさすがに気付くでしょ
だったらマイナンバー振りなおせばいいじゃん (スコア:0)
どうせ覚えないでしょうし、現状覚えられている人はまた覚え直せるでしょうし
Re: (スコア:0)
だれにも届かなそうな提案