1.ワンタイムパスワード
(1)S/KEY
| 過去問（H22春SC午前2問4） |
|---|
| ワンタイムパスワード（One Time Password）の仕組みの中で「サーバはクライアントから送られた使い捨てパスワードを演算し、サーバで記憶している前回の使い捨てパスワードと比較することによって、クライアントを認証する（H22春SC午前2問4)」 仕組みは何か？ |
↓
↓
↓
↓
↓
情報処理安全確保支援士試験の過去問からの出題ではあるが、これは難しい。最近の情報処理安全確保支援士試験ではあまり出ないと思っていもいいだろう。
まず、ワンタイムパスワード（One Time Password）は、パスワードの盗聴に備え、パスワードを1回限りにする仕組み。パスワードがたとえ盗聴されても、そのパスワードは利用できないので安全になる。
確か、電卓のようなものでパスワードを発行した記憶があります。
恐らくそれは、有名なRSAセキュリティ社のSecurIDだね。トークンと呼ばれるパスワード生成器を使い、時刻同期方式にて認証する。
それ以外にはS/KEYというソフトウェアがある。今回はS/KEYワンタイムパスワードの説明である。これが正解。
(2)時刻同期方式
情報処理安全確保支援士試験では基本となる方式である。時刻ベースのOTPとしてTOTP（Time-based One-Time Password）という言葉で表現されることもある。オンラインバンキングなどで利用されるハードウェア型のトークンや、Google認証システム「Google Authenticator」などのソフトウェア型のトークンもある。
過去問（H23NW午後2問2）に時刻同期方式の問題があるので引用する。以下はハードウェアトークン型のTOTPである。
| 引用（H23NW午後2問2） |
|---|
| 社外でTCを使用するときには，トークンを使ったワンタイムパスワード（以下，OTPという）方式の認証でセキュリティを確保する。 （中略） OTPは，時刻同期方式を利用する。社員に，あらかじめトークンと呼ばれるパスワード生成器を配布する。トークンが生成する数字は1分経過ごとに変化し，一度しか使用できない。本方式では，時刻のずれが発生するので，ずれの許容範囲を設定する。認証サーバは，許容範囲内で認証を試みて，認証できたらトークンとの時刻のずれを推定して記憶し，次回の認証時に，記憶したずれを基に時刻の補正を行う。 設問3〔社外でのTC使用時のセキュリティ対策〕について，(1)，(2)に答えよ。 (1) トークンが生成する数字を変化させる時間間隔を長くすると，トークンに表示された数字を正しく入力しても，不正パスワードになるケースが発生することがある。その理由を，20字以内で述べよ。 (2) 本文中の時刻同期方式で，ずれた時刻を認証サーバが推定する方法を，50字以内で述べよ。 |
OTPのトークンを見たことがある人も多いことだろう。
キーホルダーぐらいの大きさの機器だ。この液晶画面に表示される数字がOTP。
なぜ、時刻同期をするのですか？
「時刻」というのが、唐突な感じで、疑問です。
時刻同期をしなければ，昨日のパスワードでも、1週間前にトークンで作成したパスワードでもログインできる。つまり，ログインできるパスワードが増えるので，不正ログインのリスクが広がるからだ。
問題文に、「本方式では，時刻のずれが発生する」とありますね。
時刻同期なので、認証サーバとトークンは時刻の同期をしているのでは？
同期をしていないね。そもそも、両者はつながっていないからさ。
さて、設問の解答例は以下である。
(1)パスワードの再使用となるから
(2)認証できたパスワードが生成された時刻と，パスワードを受信した時刻の差から推測する
(3)スマホアプリによるTOTPを入力する流れ
情報処理安全確保支援士試験の過去問（H31春SC午後1問2）の図4をもとに、スマホアプリでのOTPの流れを確認する。
このままだとイメージが湧きにくいので、上記の流れを、AWSのログイン時にスマホのGoogle認証システム「Google Authenticator」によるMFA（多要素認証）で紹介する。
❶認証要求（利用者ID、パスワード）
AWSでも、まずは利用者ID（メールアドレス）とパスワードを順次問われる。
❷利用者ID，パスワードの検証
この内容は利用者には見えないので、画面キャプチャは割愛（というか存在しない）
❸OTP要求
以下がAWS画面でのOTP要求画面である。もちろん、事前にスマホと連携して初期設定がされてある。
❹現在時刻、共通鍵からOTP算出
OTP算出するプロセスは見えないが、スマホのGoogle認証システム「Google Authenticator」に、AWSにユーザXXXでログインする場合の設定がなされているので、表示されるOTPを確認する
❺利用者がOTPを入力
表示された6桁の数字（上記の場合は「696925」）をAWSの画面に入力
❻OTP
OTPがAWSに送信される（AWSの中で認証サーバに連携）
❼利用者IDに対する共通鍵を選択、現在時刻、共通鍵からOTPを検証
AWS内で検証がなされる。
❽利用者IDの認証結果
認証結果が正しければ、AWS画面にログインできる。
(4)スマホアプリによるTOTPの登録の流れ
では、実際のOTPの利用の流れがイメージできたと思うので、次は、アプリの登録処理の流れを開設する。こちらも同じ過去問ではあるが、情報処理安全確保支援士試験の過去問（H31春SC午後1問2）の図3をもとにする。
こちらもAWSでスマホによるOTP認証が行えるようにするための実際の画面を補足する。
❶OTP認証方式の利用登録要求
AWSの場合、ユーザ単位でどのような認証をするかを選ぶことができる。今回はuser1というアカウントにMFAデバイス、つまりスマホのアプリを割り当てる処理を行う。
上記の「管理」をクリック。以下の画面が表示されるので、一番上の「仮想MFAデバイス」を選択する。説明文にあるように、これが、「モバイルデバイスまたはコンピュータにインストールされたAuthenticatorアプリケーション」であり、今回はスマホのGoogle認証システム「Google Authenticator」を使う。
❷共通鍵を作成・登録
AWS内で、共通鍵が作成される。
❸ORコード（ドメイン、共通鍵）
すると、AWS側から以下のような画面が表示される。ここではドメイン、共通鍵とあるが、AWSでは内容が若干異なるかもしれない。
❹カメラでQRコードを読取り
上記のQRコードを読み込むことで、AWSのサーバの情報やユーザアカウント、共通鍵を取得する。
このとき、AWではMFAコードを2回入力させている。この手続きはAWSでは必須であるが、過去問の流れでは記載がない。時刻同期ができているかなども含めて、OTPが正しく発行されるかの確認のために入力させていると思う。
❺ドメイン、共通鍵を登録
取得したものをスマホに登録する。これで、ログインするときには、ドメインや共通鍵などの情報をもとに、OTPを発行する。
2.MACアドレス認証
| MACアドレス認証はセキュリティ対策として不十分と言われている。 なぜでしょうか？ |
↓
↓
↓
↓
↓
理由① クライアントPCでMACアドレスの偽装が簡単にできること。
最近は簡単にできなくなったようですが、昔のパソコンは、マイネットワークのプロパティで、簡単に変更ができた。
理由② MACアドレスは暗号化されないので、盗聴可能であること。
例えば、無線LANによってWEPで暗号化したとしても、MACアドレスは暗号化されない。
この２つから、MACアドレスを盗聴したうえでそのMACアドレスに偽装されるからです。
ん？
では、MACアドレスも暗号化すればいいのではないですか？
そうすれば、認証として安全ですよね？
いや、MACアドレスを暗号化してしまったら、そもそも通信ができない。どこにフレームを転送すればいいかも分からないからだ。
3.スマホアプリの利用者認証
情報処理安全確保支援士試験の過去問（H25SC秋午後1問2）を見てみよう。
| 過去問（H25SC秋午後1問2） |
|---|
| 〔スマホアプリの利用者認証〕 Ｂさんは，スマホアプリを開発するに当たり，利用者認証について情報システム部のＣ課長に相談した。次は，そのときの会話である。 Ｂさん：スマホアプリを繰返し利用してもらうために，面倒なログイン操作は初回だけにして，２回目以降は自動的に利用者が認証されるようにしたいと考えています。 Ｃ課長：２回目以降はどんな情報を用いて利用者を認証するのかね。 Ｂさん：スマートフォンには, IMEI (International Mobile Equipment Identity)などの固有の端末識別番号が付与されていますので，これを用いて利用者を認証することを考えています。 Ｃ課長：確かに端末識別番号は端末の固有コードにはなるね。しかし，①端末識別番号の特性を考えると，自分の端末識別番号を別の端末で利用されて，サービス認証に使うわけにはいかないな。 Ｂさん：そのまま使うのが問題であれば，端末識別番号を基にスマホアプリ内で②鍵付きハッシュ関数で算出したハッシュ値を使うという方法はどうでしょう。 このスマホアプリ専用の鍵を一つ用意して，スマホアプリ内に格納しておけば，不正利用を防ぐことができるのではないかと思います。 Ｃ課長：しかし，③鍵を秘密にしておくことが難しいので，その方法を採用してはいけないと思うよ。スマートフォンサイトでの利用者認証は，一般的なPCサイトと同じように考えた方がいいのではないかな。 Ｂさん：分かりました。 設問１ 〔スマホアプリの利用者認証〕について, (1)～(3)に答えよ。 （1）Ｃ課長が本文中の下線①のように判断したのは，端末識別番号のどのような特性からか。 20字以内で述べよ。 （2）本文中の下線②の鍵付きハッジュ関数を解答群の中から選び，記号で答えよ。 解答群 ア AES イ HMAC ウ RIPEMD エ SHA-256 （3）本文中の下線③について，どのような手法で鍵を知られてしまうか。30字以内で述べよ。 |
↓
↓
↓
↓
↓
詳しくは別途書きたいが、スマホ端末の個体識別番号（IMEI）は、*#06# と入力すると表示される。これとは別に、利用者を認証するSIMカードのIMSI(International Mobile Subscriber Identity)という番号もある。
端末のSIMを入れ替えた場合、両者があれば、「誰がどの端末」を使っているかの識別ができる。
正解は
(1)秘密情報ではないという特性
(2)イ
(3)スマホアプリをリバースエンジニアリングする
4.【参考】所有物認証 ICカードとPINコード
ディジタル署名機能を組み込んだICカードの利用が広がっている。パスワード認証だけの場合、パスワードが漏えいすれば、例えばインターネット上のシステムの場合に世界中のどこからでも不正利用できてしまう。しかし、ICカードなどの認証デバイスを利用した認証の場合、ICカードを持っていないと認証できない。セキュリティの強度は大幅に上がる。
さらに、会社の社員証と兼用するなどして存在価値を高めれば、ICカードの貸し借りが減り、人的なセキュリティリスクをさらに防ぎやすくなる。
また、PIN（Personal Identification Number）入力を求めて二要素認証をすることで、ICカードが盗まれてもPINが分からなければ不正アクセスされることはない。
一般的なPINの運用に関しては、情報処理安全確保支援士試験の過去問（H18SV午後Ⅰ問3）に事例が掲載されているので紹介する。
| 一般的なPINの運用に関する事例 |
|---|
| ICカードには、新規発行時に初期PINが設定され、従業員にはICカード受領後に初期PINを変更することを義務付けた。 （中略） 従業員がPINを入力し、連続して5回照合に失敗すると、そのICカードを使用不可能な状態（以下、ロック状態という）とする。従業員がPINを忘れてしまった場合や、ロック状態となった場合は、人事総務部が管理者としてICカードを回収し、ロックを解除した後、再度PINを設定して、従業員に返却する。 （H18SV午後Ⅰ問3より抜粋） |
ICカードの欠点は、ICカード読み取り装置が必要であり、初期コストがかかることである。
■補足：ICカード（USBトークン）のPIN
・証明書を利用する際に、PINコードを入力しないと利用できない。
・最初に管理者からeTokenをもらったときに、初期パスワード（PIN）が設定されているので、自分しかしらないパスワードに変更する。
・ 忘れてしまった場合は、管理者しか復旧できない。
・ PINコードや証明書には有効期限を設けておくべきであろう。
・PINロック：一定回数以上パスワード入力に失敗すると、ロックされる。※ロックを設定しないことも可能。管理者のみロック解除ができる。
・USBトークンを初期化することは可能。ただし、その場合、内容は全て削除される。
5.クレジットカードの不正使用。誰が責任をおう？
情報処理安全確保支援士試験には関係ない、余談である。
| 問題 |
|---|
| Q 知らない店からのクレジット請求がきました。どうやら、クレジット番号を不正使用して第三者がその店から購入したようです。 この場合、誰が責任をとる？ 1.利用者 2.店 3.クレジットカード会社 |
↓
↓
↓
↓
↓
状況によりますが、店（だと思われます。）
お店が本人確認などを怠ったという理由です。サインをきちんと確認しなかったなどの場合です。
3Dセキュアなどを導入していれば店の責任ではなくカード会社が保障することになるかもしれません。
とはいえ、無用なトラブルに巻き込まれたり、もやもやしないために、カードには上限額の設定をしておくとよいでしょう。カード会社によっては、自動増額設定がされてある場合があります。いつのまにか上限が１００万円という大金になっている場合があります。クレジットカード会社への確認も必要ですね。
話が変わりますが、解約したカードがあるんですけど、そのカードから請求書が届きました。しかも、私の銀行口座から引き落としをするんですって。びっくりしました。
その点は、知らない人もいるが、そうらしい。
クレジットカードを解約したら、カード会社との関係が切れると思っていたが、某社（だけ？）の場合は7年間、情報を保持するということ。つまり、その間に請求が来たら、銀行口座から引き落とされる。
今回の場合は、私が年間契約の支払い情報を変更していなかったのが原因。だから、私の責任と思っている。でも、不正な第三者が請求をした場合でも、同じように請求されることがあるということが分かった。
そう。だから、初回の特典を期待して、カードをたくさん作るという行為はやめた方がいいだろうね。
