パスワードを忘れた? アカウント作成
13440330 journal
数学

yasuokaの日記: 末尾が「01」のマイナンバー 6

日記 by yasuoka

とあるイキサツで、2015年12月21日の日記を横目に、マイナンバーのチェックディジットの弱点について、私(安岡孝一)なりに少し考えてみた。マイナンバーのチェックディジット(12桁のうち末尾の1桁)は、上から順に各桁をa,b,c,d,e,f,g,h,i,j,k,lとする時、(6a+5b+4c+3d+2e+7f+6g+5h+4i+3j+2k)を11で割った余りをpとおくと、p≦1に対してはl=0、その他のpに対してはl=11-pとするものである。

すぐに思いつく例が、末尾が「01」のマイナンバーだ。末尾が「01」のマイナンバーは、末尾を「10」に変えてもエラーにならず、素通しされてしまう。つまり、末尾が「01」のマイナンバーは、末尾2桁の入替エラーを検出できない。というのも、abcdefghij01が正しいマイナンバーなら、(6a+5b+4c+3d+2e+7f+6g+5h+4i+3j)を11で割った余りは10になっており、k=1ならばp=1でl=0、がチェックディジットになってしまうからだ。

次にイラっと来る例が、末尾が「30」のマイナンバーだ。末尾が「30」のマイナンバーは、末尾を「80」あるいは「90」と打ち間違っても、それぞれ50%の確率で素通しされてしまう。というのも、abcdefghij30が正しいマイナンバーなら、(6a+5b+4c+3d+2e+7f+6g+5h+4i+3j)を11で割った余りは5か6になっており、5の場合はk=9が、6の場合はk=8が、それぞれl=0を満たしうるからだ。「3」と「8」と「9」は、けっこう見間違えが多いので、かなり危険だったりする。

このあたりをもう少し広げていくと、末尾のチェックディジットが「0」のマイナンバーは、他の各1桁(a~k)の単純な打ち間違いを、11%ほど素通ししてしまう。チェックディジットとしては、ダメダメだということだ。ただ、今さらDammアルゴリズムに変えるわけにもいかないし、さて、どうしたものかしら。

この議論は、yasuoka (21275)によって ログインユーザだけとして作成されたが、今となっては 新たにコメントを付けることはできません。
  • by onetime_id (39093) on 2017年10月27日 8時56分 (#3302290) 日記

    ツイッターで同様の話題が出たときに
    「訴訟とか出来ないかな」
    って言ってみたのですが、どうなんでしょうね。
    該当する番号の人で集団訴訟という流れ。

    紛失時に届け出れば変更できるらしいので番号変更スキームはあるようなのですが、
    制度不備のせいなのに費用負担させられるのは嫌だといって訴訟にする。
    # 正直その辺の手間ってお金(500円)払ってしまうより高コストですが。。。

    もし認められた場合、運用で回避という形で該当するチェックデジットになる番号は
    使用しない(払い出し番号の対象外とする)あたりに落ち着くだろうな、と思います。

  • 直感的には「1/11(9%)の割合で検出できないケースがありそう」と思ったのですが…

    もしかしたらすでにお読みになられてるかもしれませんが、上原哲太郎氏の考察 [digitalforensic.jp]によると、末尾チェックデジットが0の場合、
    ・「隣あう数字が入れ替わった場合」の9.6%が検出できない
    ・「ある一桁の数字を間違えた場合」の9.1%が検出できない
    そうです。

    モンテカルロな調査なので数式的な説明はありませんが、そういった操作で mod 11 が1→0または0→1と変化する(そのためどちらもチェックデジットが0になる)ような数字列が9.6%/9.1%の割合で存在する、という話で。

    • 「11%ほど」ってところは、私(安岡孝一)自身ちゃんと条件を書いてないのですが、まあ、予想される最悪値なのです。例を挙げると、「000000000000」っていう(絶対に使われない)マイナンバーに対しては、各桁は、上から順に2,9,3,4,6,8,2,9,3,4,6っていう打ち間違いが素通しされうるので、「11%ほど」だったりします。もちろん平均値は、もう少し下がるかもしれません。

      親コメント
      • なるほど了解しました。
        そういう考え方でしたら、上原氏の調査では「平均値で9.1%になる」ということになりますかね。

        親コメント
        • 平均値は、うーん、「ある一桁の数字を間違えた場合」の「ある一桁」にチェックディジットを含んでない場合は1/10、含んでる場合は11/120あたりになるかしら。いえ、その、まだ真面目に検討してないので、間違ってたらごめんなさい。

          親コメント
          • 私もちょっと考えて見ました。

            チェックデジットが0のままであるためには、p が 1 だけずれる必要がありますが、mod 11 は11通りなのに各桁の数字は10通りしかないので、ある一桁に対して、1/10の割合で「mod 11 が1つずれるような数は存在しない」ことになり「ある一桁の数字を変えても、チェックデジットがやっぱり0になる」ような間違いが存在するケースは 9/10 だけ。
            (例えば、000000000140は、j = 1、k = 4 → sum = 11 → p = 0 で、チェックデジット 0 ですが、p = 1 になる(k×2 mod 11 = 9 になる) k は存在しませんので、kの桁では、間違えてもチェックデジットの衝突するケースはありません)

            そのため、桁毎に見て「その1桁を変えて、チェックデジットが0のまま」な数の存在割合が9/10で、それが11桁あるので、
            ある数値に対して「ある一桁の間違いだけどチェックデジットが一致する数値」の数は平均(9×11/10)個。

            結果、
            「ある一桁」にチェックディジットを含んでない場合は、「ある一桁の間違い」が各桁9通り×11桁なので、衝突割合は (9×11/10)/(9×11) = 1/10。
            「ある一桁」にチェックディジットを含む場合は、「ある一桁の間違い」が各桁9通り×12桁なので、衝突割合は (9×11/10)/(9×12) = 11/120。
            になる、って感じでしょうか。

            親コメント
typodupeerror

UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie

読み込み中...