パスワードを忘れた? アカウント作成
12855543 story
バグ

マイナンバーのチェックデジットは仕様上入力ミスを検知できない場合がある 77

ストーリー by hylom
なんとまあ 部門より

マイナンバーでは入力間違いがあった場合にそれを検出できるよう、マイナンバーの最下位(一番右側の1桁) が「チェックデジット」に割り当てられている。チェックデジットの一般的な実装では、ナンバーの各桁を特定の数式で処理することで入力されたナンバーが間違っていないかどうかを検出できるのだが、マイナンバーのチェックデジットでは実装の仕様上、入力ミスの仕方によってはそれを検出できないのだという(デジタル・フォレンジック研究会の第404号コラム「マイナンバーのチェックデジットについて」)。

たとえばチェックデジットが0の場合、1桁の入力ミスのうち約9.1%を検出できないという。さらに法人番号については「0」と「9」を取り違えた場合、間違いを検出できないという。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by ikotom (20155) on 2016年07月26日 4時49分 (#3052946)

    正直なところ、わたしはそもそも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とかライセンスシリアルとかはそれ自体が単体でキーとなりうるものなので
    チェックディジットは必須ですが、マイナンバーは単体では意味がないものです。
    (少なくとも私の理解では)
    ゆえに番号それ自体のチェック機構は限り無く不要に近い、ということですね。

    • by Anonymous Coward on 2016年07月26日 8時41分 (#3052986)

      「12桁の数字」がマイナンバーか否かを判定する材料になるので、必要。

      具体的には、メールゲートウェイやプロキシで、「12桁の数字」をアップロードしようとしたら、
      その数字のチェックデジットを確認し、マイナンバーの可能性があればブロックする、という
      運用が可能。(そういう機能を持つ機器が既にいくつも存在する)

      入力誤りの検知目的としては、そこまで重要ではないんだろうけど。

      親コメント
    • by Anonymous Coward

      運用上、連番を順繰りに附番していくケースではチェックデジットが有効だと思うけれど、
      連番を避けるような運用を前提とするならあんまり意味ないと思うんだよね。
      そういう前後の番号が参照されることを避ける附番を行うシステムにしているなら、
      番号単独での個体照合・突合なんてのはまず行われないし。

    • by Anonymous Coward

      つまり必要もないもののために入力量を10%も増加させてると。

  • 入力ミスを検知できない場合が「ある」。有るか無いかだと、あって当たり前ですが。
    ここでの問題は1桁の入力誤りを 検知できない率が「高い」点だと思います。
    デジタル・フォレンジック研究会 の文章によるとマイナンバーの設計では
    「この見逃しは検査用数字が0の時のみ発生しますので、
    この場合に限ると実に1桁誤りの約9.1%を検出することが出来ません。」とのこと。 
    数字のケタをケチらずチェックデジット2ケタで設計しても良かったと思いますけど。
    なおオマケで懐かしネタ1980年代のマイコン誌と16進数ダンプリストとチェックサムの記事。
    「にがMSX OCRとMSXを利用してオールドPCのダンプリストを入力する」 [sytes.net]

    • by Anonymous Coward on 2016年07月26日 1時00分 (#3052928)

      そりゃチェックディジットの桁数を増やせば検出率は上がりますが、そんなのは自明で指摘するまでもないことでは。
      桁数や文字種を増やせば入力効率は当然低下するわけで、そこにはトレードオフがあります。
      マイナンバーを11桁から12桁に増やすということは、9.1%もの入力量増加になるわけで、それについて考慮しなくてよいのでしょうか?
      1桁の誤入力の場合の検出率が特定のケースで91.9%だからというだけの理由で現行の方法を批判するのが、公平な意見とは思えません。

      元記事はVerhoeff algorithmというマイナーなアルゴリズムを使うと、1桁の数字のみのチェックディジットでも
      よい検出率を実現できるという紹介で、主眼はこちらではないでしょうか(私が見た時点では、コメントで誰一人言及していないようですが)。

      親コメント
    • by Anonymous Coward

      それもあるけどよりによって間違えやすい0と9だからなぁ。

      • by Anonymous Coward on 2016年07月25日 21時26分 (#3052851)

        アラビア数字なんか使わずに漢数字にすれば良かったのに

        親コメント
        • by Anonymous Coward

          やめてください漢数字で入力を強制するWebフォームに疲れ果てて死んでしまいます

      • こういうの入力する場合はテンキーを使うでしょう。

        無刻印HHKを使ってる? 0と9を打ち間違えるようじゃ修行が足りんでしょう。:-)

        親コメント
        • by Anonymous Coward

          打ち間違いじゃなくて見間違いの話でしょう。字体によると思うけど。
          #手書きだと79が(たまに4も)怪しい

          • by Anonymous Coward

            0と9を間違えやすい字体ってあんまり見かけないかな。
            6と8と9を判別しづらいケースの方が圧倒的に多い。
            あとは斜線付きの0と8。

            手書きのときは2と7と1とか、4と9とか、3と5で識別しづらい字を書く人が結構いる。

        • by Anonymous Coward

          最近 ノートPCも多いから、そもそもテンキーない環境もあるんじゃないかな。

  • by Anonymous Coward on 2016年07月25日 19時49分 (#3052795)

    チェックデジットをアルファベットにしたらいいだけではないの?

    • by Anonymous Coward

      間違えても通ってしまうのが問題なんだからアルファベットにしたところで意味はないだろう
      マイナンバーのSHAを入力してもらえばいい
      入力ミスしても通ることはまずない

      • by taka2 (14791) on 2016年07月25日 21時49分 (#3052860) ホームページ 日記

        ちゃんとリンク先を読め、で終わる話なんですが説明しとくと、個人用マイナンバーと法人用マイナンバーでは全然別のチェックデジット付加方法を採用してますが、

        個人用マイナンバーは、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 で、今回のネタのような問題はありませんし。

        親コメント
        • by Anonymous Coward

          不思議なんですが、そういう問題があることが明らかなのになんでチェックサムの計算方式ではmod 9やmod 11が主流なんでしょうか。かつてのrand関数みたいに特に理由もなく昔から使われているものが使われているだけなんでしょうか。

          • by taka2 (14791) on 2016年07月26日 13時13分 (#3053144) ホームページ 日記

            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にしとこう」という安直な考え方で作られたんじゃないかと思ってしまいます。

            親コメント
      • by miyuri (33181) on 2016年07月25日 20時13分 (#3052811) 日記

        とりあえず、ECCを付けて、入出力を機械任せにしてみてはどうだろうか。

        親コメント
      • by Anonymous Coward on 2016年07月25日 20時50分 (#3052834)

        >>「0」と「9」を取り違えた場合、間違いを検出できないという。

        まずこのリンクを読んでから書き込みして欲しい。

        親コメント
      • by Anonymous Coward

        高々12桁の10進数字に、最低でも20バイト必要なSHA [wikipedia.org]を使うとか全然意味ないだろ。

  • by Anonymous Coward on 2016年07月25日 19時57分 (#3052800)

    はい?なんのためのチェックデジットなんだろか、、、

    • by Anonymous Coward

      必ず検知できるんだったら、単なる冗長化やん

      • by Anonymous Coward on 2016年07月25日 21時41分 (#3052857)

        > こうしてみると、結局のところOCR(パスポートの場合)、バーコード(牛個体番号)、マークシート(大学入試センター)といった光学的な機械読み取りが前提となっているコードにはチェックデジットが抵抗なく、かつ比較的「正しく」導入されてきたのに、事務処理上機械入力されることが前提になっておらず、人による手入力が前提になっている運転免許証などのコードにはチェックデジットが導入されないか、導入されるとしても深く考えられていないものが用いられている傾向が感じられます。

        元記事は「確実に検知できないからゴミ」と言いたいわけではないらしい
        書類仕事が自動化される時には暗号学の素養が必要なアルゴリズム選択が雑になりがちということを嘆いているんだろうか

        親コメント
        • by Anonymous Coward on 2016年07月25日 22時58分 (#3052889)

          つまり、事務処理で用いられるコードに対してどのようなチェックデジットを与えるのが適切かという判断基準がなく、それが(人手の作業も含む)事務処理上の効率化において鍵になるという発想が共有されていないのが問題だろうと思うのです。
          ...
          それと同様に、チェックデジットに限らずICT機器と人が連携して事務処理を行う際に、技術的な勘所に対して何らかの基準を満たすことを促すような仕組みが、国の機関のどこかに必要な気がするのです。

          雑なのを嘆くとともに、そもそも必要性が認識されてない事も言いたいようだ。

          思うに、人が介在するシステムの問題は、介在する人にも責任が分散してしまうから解決が後手になるんだと思う。なにごとにつけ。

          親コメント
      • by Anonymous Coward on 2016年07月25日 21時20分 (#3052845)

        チェックデジットの一般的な実装では、ナンバーの各桁を特定の数式で処理することで入力されたナンバーが間違っていないかどうかを検出できるのだが

        実装によって若干の差はあるが、チェックデジットが1桁なら「入力ミスでも1/10に近い確率で通ることはある」

        いやまあ、たとえば「各桁の数字を足して下1桁をチェックディジットにする」みたいな原始的な方法なら「1桁の入力ミス」は確実に検知できるけど
        今度は「12345678」と「12354678」みたいな間違いを検知できない

        チェックディジットは単純に「誤入力の確率を減らす」だけで「誤入力を確実に検知できる」ものではないんだよなぁ
        確実に検知したけりゃ親コメの言うように冗長化するしかない

        親コメント
        • by Anonymous Coward

          これ読んでいないよね。

          分かりやすくするため、個人番号を11桁の数字abcdefghijkxとしますと、
          検査用数字xはx = 11 – (6a + 5b + 4c + 3d + 2e + 7f + 6g + 5h + 4i + 3j + 2k) mod 11 ただしx≧10ならx=0です。
          これなら、まだしもわかりやすいでしょうか。

          • by Anonymous Coward

            その分かりやすい説明で何がわかったと思ってるのか
            わかんないなぁ

            • by taka2 (14791) on 2016年07月26日 2時13分 (#3052937) ホームページ 日記

              まあ確かに、あのコメントで意味が分かるような人は、#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になるなど)は検出できません。
              それでも、「各桁の数値を間違える」「隣り合う数値が入れ替わる」という「人間がやってしまいがちな入力ミス」に対抗するには、こういう式でも十分効果があると考えられており、これが実用に供されているわけです。

              親コメント
              • by Anonymous Coward

                チェックデジットが数字1桁である以上、全部合わせれば確率10%で通ってしまうのは避けようがないけど、人間がやりがちな間違いに検知率を偏らせるように工夫がされてるってことですよね。平均すればデータ量の増加は避けようがないからといって可逆圧縮が不可能ではないように。

                # しかし#3052845のようなボケたコメントがプラスモデされるのが今のスラドクォリティ

      • by Anonymous Coward

        1桁の入力ミスを検知できないことがあるチェックデジットなんてゴミでしょ

  • by Anonymous Coward on 2016年07月25日 20時15分 (#3052814)

    ソースで軽く触れてますが、
    仕様として決めてはいるけどそもそも割り振ってないってこともあるのでは。

    • by cyceo (37981) on 2016年07月25日 20時54分 (#3052837)

      私のチェックデジットは0でした。ということで、普通に割り振ってあるようですよ。

      親コメント
      • by Anonymous Coward

        正確には、「計算して本来10であるべきだけど0が割り振られた人」が居るかどうかですね。
        そういうケースに該当してるかわかりますか?

  • by Anonymous Coward on 2016年07月25日 20時47分 (#3052832)

    どこの誰がそういう仕様にした(仕様を作った)んでしょうか
    晒し上げない駄目でしょ

    • by Anonymous Coward

      リンク先に書いてあるよ。

      こいつはよくあるチェックデジットです。
      気休めなんで、べつに実用上は問題ないんじゃないの?

      まじめに作るならエラーはホワイトなのかとかも
      気になってきますね。リンク先で紹介されてるのは
      そのへんも少しは考慮されていると思います。
      入れ替えとか言ってるので、多分。

      実用的なところを気にするなら、どんなエラーを救いたいのか、
      ホワイトとするとBERはどれくらいが目標なのか、
      だいたい符号化率に大きな制約があるわけじゃないだろうとか、
      気になってきます。

      で、リンク先のもだけど、故意になんかした場合の強度とかは
      考えてないでしょう?
      これはあくまで入力間違いチェックの第一関門ですよ。
      出てきた名前見ればわかるじゃん。

  • by Anonymous Coward on 2016年07月25日 22時40分 (#3052883)

    >>こうしてみると、結局のところOCR(パスポートの場合)、バーコード(牛個体番号)、マークシート(大学入試センター)といった光学的な機械読み取りが前提となっているコードにはチェックデジットが抵抗なく、かつ比較的「正しく」導入されてきたのに、事務処理上機械入力されることが前提になっておらず、人による手入力が前提になっている運転免許証などのコードにはチェックデジットが導入されないか、導入されるとしても深く考えられていないものが用いられている傾向が感じられます。

    要するに手入力する時にテンキーだけ使って入力したいからそうしたんだろうね。
    かなり鋭い意見だね。
    チェックデジットはエラーを発見する為にあるからそこを悪くしたら駄目なんだよね。
    そうならそうと言えば、ちゃんとしたまともな人が対案を出してくれるはずなのに自分達の意見が正しいからパブリックコメントは見ないとかやっているからこうなる。
    チェックデジットをアルファベットにしても問題ないでしょ。
    例えば入力画面で11桁+2桁入力(アルファベット)って2桁を打ってアルファベットに変換するだけでいいんだし。
    なんでこんな簡単な事をやるのに不具合がでるようなシステムにしているんだろうね。

  • by Anonymous Coward on 2016年07月25日 22時45分 (#3052886)

    個人番号同士、法人番号同士の誤り検出能力も重要ですが、これらの桁数が違うことから

    ・個人番号12桁の入力時に1桁打ち過ぎて、法人番号と重なる
    ・法人番号13桁の入力時に1桁打ち飛ばして、個人番号と重なる

    というケースはどうなんでしょう。
    (代数的には当然一致するコードはあるけど、付番の仕方から事実上問題ないこともあり得るのでよく分からん)

    • by Anonymous Coward

      個人番号と法人番号は用途が異なると思うので、どちらを入れても良い場合ってのがそもそもあるのかどうかと、もしあるなら別途どちらかを指定させれば済む話じゃないか?

    • by Anonymous Coward

      法人と個人の取り違えはさすがに気付くでしょ

  • by Anonymous Coward on 2016年07月25日 23時37分 (#3052908)

    どうせ覚えないでしょうし、現状覚えられている人はまた覚え直せるでしょうし

    • by Anonymous Coward

      だれにも届かなそうな提案

typodupeerror

物事のやり方は一つではない -- Perlな人

読み込み中...