List of Nist [text.Baldanders.info]

NIST SP 800-63-4 最終版がリリース

2025-08-28T08:34:43+00:00

以前「誰が「パスワードは複雑なものにしろ」と言ったのか」でちょろんと紹介した NIST SP 800-63-4 の最終版が2025年7月に公開されたようだ。見落としてたよ。

これは以前の NIST SP 800-63-3 を置き換える内容となっている。 NIST のブログ記事によると，主な変更点は以下の通りらしい。

Updates to context setting for risk management, reframed risk management processes, and new expectations for greater cross-functional engagement.

New recommended continuous evaluation metrics.

Expanded fraud requirements and recommendations for identity proofing processes.

Restructured identity proofing controls to better define roles and types of identity proofing.

Added controls for addressing injection attacks and forged media (e.g., “deep fakes”).

Integration of syncable authenticators (e.g., synced passkeys).

Representation of subscriber-controlled wallets in the federation model.

via Let’s get Digital! Updated Digital Identity Guidelines are Here!

とりあえずこの記事ではリンクのみ指示しておく。そのうち詳しく話す機会があるかもしれない。

ブックマーク

参考図書

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

[Comment] 原書のタイトルが “Beyond Fear: Thinking Sensibly About Security in an Uncertain World” なのに対して日本語タイトルがどうしようもなくヘボいが中身は名著。とりあえず読んどきなはれ。ゼロ年代当時 9.11 およびその後の米国のセキュリティ政策と深く関連している内容なので，そのへんを加味して読むとよい。

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

信頼と裏切りの社会: ブルース・シュナイアー (著), 山形浩生 (翻訳); NTT出版 2013-12-24; 単行本（ソフトカバー）; 4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (ISBN); 評価

[Comment] 社会における「信頼」とは。

reviewed by Spiegel on 2015-11-28 (powered by PA-APIv5)

誰が「パスワードは複雑なものにしろ」と言ったのか

2024-12-02T14:06:54+00:00

いつものように yomoyomo さんの記事を起点に小咄を。

長年の誤ったパスワードポリシーが推奨された原因はあの偉人の論文だった？ - YAMDAS現更新履歴

この記事の元ネタが更にあって，ボクらの Bruce Schneier 先生の記事で紹介されている以下の記事。

How some of the world’s most brilliant computer scientists got password policies so wrong | Mildly-Aggrieved (not mad!) Scientist

これは古のパスワード生成ルール「パスワード文字列は英数字と記号の三種盛りにしろ」とか「パスワードは定期的に変更しませう」とかの元ネタが何かって話らしい。記事によると Robert Morris さんと Ken Thompson さんが1979年11月に公開した “Password Security: A Case History ” という論文が大元なんだとか。 Ken Thompson さんは Go 言語開発者のひとりなんだね。

First, was Morris and Thompson’s confidence that their solution, a password policy, would fix the underlying problem of weak passwords. They incorrectly assumed that if they prevented the specific categories of weakness that they had noted, that the result would be something strong.

via How some of the world's most brilliant computer scientists got password policies so wrong

この記事では言及されてないが，更に悪いことに，この考え方で NIST SP 800-63 のほうも実装されてしまったらしい。このせいで悪名高きパスワード生成ルールが世に蔓延ることになったわけだ。

以下は改訂された NIST SP 800-63-3 が正式リリースされた2017年の ZDNET Japan の記事。

　大文字、小文字、数字、記号を使った覚えにくいパスワードを作らされ（しかもそれを定期的に変更することを義務づけられ）て、どうしてこんなルールがあるのかと憤ったことがある人は多いだろう。それはおそらく、どこかの開発者が、米国立標準技術研究所（NIST）が2003年に作成した文書に従ったためだ。

　この8ページの「NIST Special Publication 800-63別表A」は、NISTの元管理職であるBill Burr氏によって作成された。同氏はすでに引退しており、今では72歳になっている。

　Burr氏は、The Wall Street Journalの取材に対して、「今では、わたしが決めたことの大部分について後悔している」と語った。

あの「面倒なパスワード作成ルール」、作った人も後悔していた - ZDNET Japanより

“How some of the world’s most brilliant computer scientists got password policies so wrong” では更に

That mistake was their recommendations on how passwords should be stored. They recommended that systems should not store passwords, but instead assign each user a random “hash” function used to compute a number (the hash) from that users’ password.

[…]

Storing numeric hashes instead of the passwords can protect users whose passwords are hard to guess, but it also prevents scientists from examining those passwords to determine if there might be categories of common (weak) passwords that users should be discouraged, or prevented, from choosing. While Morris and Thompson did not invent password hashing 3, they implemented it into Unix, strongly recommended it, and their paper would be the one most cited to support the necessity of password hashing.

via How some of the world's most brilliant computer scientists got password policies so wrong

などと書いている。ユーザによるパスワード生成の実態をサービスプロバイダ側が把握できなかったせいで「間違い」が放置されたままだったというのだ。少なくとも論文が登場した1979年には公開鍵暗号は発明されてたんだからハッシュ関数を使うのではなく公開鍵暗号を使えばよかったとか言ってるようだ。

まぁ「研究者」としてならこれはこれで正しいのかも知れないが，エンジニアとしてはパスワード情報の秘匿に公開鍵暗号を使うのが「善」なのか首をひねるところがある。そもそも記事で挙げている RSA は20世紀当時は特許でガチガチに固められていて，しかも米国外では（軍事的な理由で）使用不可なアルゴリズムだったので，実質的には無理な話だったと思う。

いや，パスワードを（ハッシュ化ではなく）暗号化するのはいいけど，その鍵をどうやって管理するのかって話ですよ。厳格な管理が要求される Bitcoin 交換所でもたまに漏洩事件が起きたりするんだよ。

もしもの話として，パスワードを公開鍵暗号の公開鍵で暗号化するとして，ひとつの鍵ペアで全部のパスワードを暗号化するわけないし（そんなことして万が一秘密鍵が解読されたり漏れりしたら全ユーザのパスワードが晒されてしまう），そうなるとユーザごとに鍵ペアが必要ってことになるだろう（無数の鍵ペアを使うにしても秘密鍵をひとつところに置いていれば同じことだがw）¹。つか，そんなことするくらいならパスワード認証なんかやめて公開鍵暗号を使って認証すればいいぢゃん。 ssh みたいに。

パスワード生成のルール化はどちらかというとユーザ体験（UX; User eXperience）の問題と言える。パスワードの複雑化や定期更新を強制するのは，そのほうがシステム管理側が楽だからだ。そして面倒な部分をユーザ側に「転嫁」しているのだ。セキュリティ・マネジメントの観点で「転嫁」戦略は悪いことではないが，不特定のユーザにそれを強いてもユーザはただ迂回するだけである。これは「悪い UX」の典型と言える。

そういえば『はじめて学ぶビデオゲームの心理学』に UX の起源みたいな話があって

ドナルド・ノーマン（大きな影響力をもつ『誰のためのデザイン？ —— 認知科学者のデザイン原論』（Norman, 1990）の著者）は「ユーザー体験（UX：user experience）」という単語を提唱し、製品やそのエコシステム（マーケティング、ウェブサイト、顧客サービスなど）にユーザーが関与するときの体験全般を考えるという方針を示しました。そのため、企業やグローバル戦略も UX に含まれます。

『はじめて学ぶビデオゲームの心理学』 p.34より

という感じに UX 自体が1990年代以降の考え方らしい。ルールによってユーザの行動がどう変わるかみたいな話を1979年の論文で考慮しろってのが無理筋である。

まぁ，歴史に「たられば」はないっちうことやね。

ところで，最初に挙げた yomoyomo さんの記事を読んで気がついたのだが NIST SP 800-63-4 のドラフト版って2022年に公開されてるんだね。しかもパブコメの募集は先々月の10月で締め切られているらしい。

NIST SP 800-63 Digital Identity Guidelines

まぁでもここから正式版が出るまでが長いならなぁ NIST は。気長に待ちましょうか。

ブックマーク

参考図書

暗号化プライバシーを救った反乱者たち: スティーブン・レビー (著), 斉藤隆央 (翻訳); 紀伊國屋書店 2002-02-16; 単行本; 4314009071 (ASIN), 9784314009072 (EAN), 4314009071 (ISBN); 評価

[Comment] 20世紀末，暗号技術の世界で何があったのか。知りたかったらこちらを読むべし！

reviewed by Spiegel on 2015-03-09 (powered by PA-APIv5)

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

[Comment] SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

はじめて学ぶビデオゲームの心理学脳のはたらきとユーザー体験（UX）: セリアホデント (著), 山根信二（監修） (著), 山根信二 (翻訳), 成田啓行 (翻訳); 福村出版 2022-12-15 (Release 2023-07-03); Kindle版; B0C9Z7KGRN (ASIN); 評価

[Comment] Kindle 版が出ている。ゲームデザイナやゲームエンジニアだけでなく，ソフトウェア・エンジニアは全員読むべき。あと，ゲーマーな人も読むといいよ。感想はこちら。

reviewed by Spiegel on 2023-11-21 (powered by PA-APIv5)

さらに別のもしもの話として，生のパスワード情報を暗号化してどっかに保持って（実際の認証ではなく）統計情報にのみ使うとして，その結果をユーザの行動にどう反映させるのか，という問題もある。メディアで定期的にヤバいパスワードランキングが公表されるが，あれはそういったパスワード情報が既に攻撃手段として用いられている（だろう）と分かってるからできることだ。一方，私たちユーザ側の考え方としては，拙文「「パスワードのベストプラクティス」が変わる」でも書いてるが「パスワードを覚えるなんて脳みその無駄使い」である。人間は複雑というか機械が予測不能な文字列をいくつも思いつけるようにはできていない。パスワード認証を使うならパスワード管理ツールで生成も管理も任せてしまったほうが安全ってことだと思う。 ↩︎

NIST FIPS 186-5 および SP 800-186 正式版がリリースされた

2023-02-04T00:30:31+00:00

長い間ドラフト状態だった FIPS 186-5 および SP 800-186 の最終版が出たようだ。

この記事では FIPS 186-5 に注目して書いてみる。

大きな変更は3つ。

DSA が標準から外れる

Prior versions of this standard specified the DSA. This standard no longer approves the DSA for digital signature generation. However, the DSA may be used to verify signatures generated prior to the implementation date of this standard. See FIPS 186-4 [7] for the specifications for the DSA.

via “Digital Signature Standard (DSS)” section 4

ということで予定通り，電子署名生成用途としては， DSA は NIST 標準から外れることになった。ただし，以前に DSA で作成された署名を検証する必要があるため，アプリケーションによっては実装を残しておく必要がある。 DSA 実装に関しては旧版の FIPS 186-4 を読めってあるな。

ECDSA 自体を定義し直す

今まで ECDSA の実装については，以前の FIPS 186-4 だけでは完結してなくて， ANSI X9.62 なんかも併せて参照する必要があった。特に ANSI X9.62 は所謂 paywalled document って奴で，誰でも気軽に見れるもんじゃないのね。

まだ中身をちゃんと読んでないのだが，この版ではそういった外部参照を取り払って FIPS 186-5 のみで実装を定義しているようだ。めでたい！言い方を変えると，今後 ECDSA を実装する際は FIPS 186-5 を見ろってことでもある。まぁ，私を含めて殆どの人は偉い人が作ったライブラリを利用するだけで，中身を気にする人は少ないだろうけど（笑）

EdDSA が標準として承認された

そして最大のトピックは EdDSA が NIST 標準として承認されたことだろう。

ちなみに EdDSA については，日本の CRYPTREC でも評価が行われていて

総評：下記の観点から、EdDSA の構成に関わる安全性において、EdDSA が ECDSA に劣ると考えられる点は無いと思われると述べている。

Schnorr 署名をもとに EdDSA は構成されているため、ランダムオラクルモデルで安全性が証明されている Schnorr 署名に対する安全性評価を参考にすることができる。

Schnorr 署名との大きな違いはノンスの生成方法であるが、EdDSA におけるノンスの生成方法は、署名の内部乱数を弱い疑似乱数生成器に委ねることによる危険を排除し、現実的な脅威を回避するための配慮が施されている。

比較対象となる ECDSA については、既存結果として generic group model でのみ安全性が証明されている。

CRYPTREC Report 2020 暗号技術評価委員会報告より

と書かれている。まぁ，これで政府調達でも何でも大手を振って EdDSA を使えるというものである。

めでたい！（大事なことなので2度言いました）

ブックマーク

参考図書

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

[Comment] SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

暗号化プライバシーを救った反乱者たち: スティーブン・レビー (著), 斉藤隆央 (翻訳); 紀伊國屋書店 2002-02-16; 単行本; 4314009071 (ASIN), 9784314009072 (EAN), 4314009071 (ISBN); 評価

[Comment] 20世紀末，暗号技術の世界で何があったのか。知りたかったらこちらを読むべし！

reviewed by Spiegel on 2015-03-09 (powered by PA-APIv5)

それはワンタイム・パスワードの問題ではない

2021-11-07T09:28:00+00:00

いやさ

狙われるワンタイムパスワード、多要素認証を破る闇サービスが浮上：この頃、セキュリティ界隈で（1/2 ページ） - ITmedia NEWS

て酷い釣りタイトルだよな，と思いつつモニタにツッコんでしまったよ（笑）

ハッキリ言おう。それはワンタイム・パスワードの問題ではない。

ワンタイム・パスワードに問題がないわけではない。 NIST SP 800-63B によればスマホの TOTP アプリや専用のワンタイム・パスワード機器は「単要素 OTP デバイス（Single-Factor One-Time Password (OTP) Device）」と呼ばれる。これはタイプとしては「知識」ではなく「所有」に分類される。所有型の Authenticator には紛失・盗難のリスクが伴う。また，基本的に OTP は認証する側とされる側との間で最初にシークレットを共有する必要があり（特にアプリでは）シークレットの受け渡しと管理の問題が発生するが，認証の段階でこのシークレットをやり取りすることはない。

しかし，上の記事の「ワンタイムパスワード」はこれとは異なる。 SMS やチャット・アプリ等を通してサービスプロバイダから使い捨てシークレットを通知し，シークレットをもらったユーザは通知を受けたチャネルとは別のチャネル（大抵はスマホ・アプリかブラウザで表示される Web ページ）でシークレットを返す。送ったシークレットと返ってきたシークレットを比較して認証を行うわけだ。こうした仕組みは NIST SP 800-63B の分類では「経路外デバイス（Out-of-Band Devices）」と呼ばれている。

経路外デバイスが筋が悪いのは攻撃者から見て攻撃ポイントが多いことだ。上の記事で示される事例はまさにそこを突かれて認証を突破されている。

以前に拙文「Authenticator と AAL」で紹介したが，元々 NIST は SMS を使った認証を非推奨（または禁止）にするつもりだった。

SMSを使った二要素認証を非推奨〜禁止へ、米国立技術規格研究所NISTの新ガイダンス案 | TechCrunch Japan

しかしその後，色々あったようで，最終的には “RESTRICTED Authenticator” という位置づけまで緩和されてしまった。

The use of a RESTRICTED authenticator requires that the implementing organization assess, understand, and accept the risks associated with that RESTRICTED authenticator and acknowledge that risk will likely increase over time. It is the responsibility of the organization to determine the level of acceptable risk for their system(s) and associated data and to define any methods for mitigating excessive risks. If at any time the organization determines that the risk to any party is unacceptable, then that authenticator SHALL NOT be used.

via NIST Special Publication 800-63B

でも，結局その「温情措置」が重大なセキュリティ・インシデントを招いているのだから「なんだかなぁ」という感じである。電子メールや VoIP が経路外デバイスとして NG なら SMS だって NG だろう。

Authenticator による認証には3つのレベル（Authenticator Assurance Level; AAL）があるが，最初の記事の事例にあるような「暗号資産」を扱う重要な決済システムなら AAL3 は必須だろうし，そうであるなら認証手段として経路外デバイスを選択するのはあり得ない。これは「闇」でも何でもなく，単にサービス・プロバイダが間抜けで迂闊だったというだけの話である。

道具は適切に組み合わせないと所定の性能を発揮できない。私達エンジニアはこのことを肝に銘じておくべきだし，利用者としても「利便性はセキュリティとトレードオフできない」ことは知っておくべきだろう。

参考図書

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

信頼と裏切りの社会: ブルース・シュナイアー (著), 山形浩生 (翻訳); NTT出版 2013-12-24; 単行本（ソフトカバー）; 4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (ISBN); 評価

[Comment] 社会における「信頼」とは。

reviewed by Spiegel on 2015-11-28 (powered by PA-APIv5)

DSA は NIST 電子署名標準から外れるようだ

2021-02-17T11:53:55+00:00

Go 1.16 のリリースノートを眺めていて今さら気付いたのだが，いまだドラフト中の FIPS 186-5 によると， DSA を「電子署名生成用途としては」電子署名標準（Digital Signature Standard; DSS）から外すつもりのようだ。ドラフト版 FIPS 186-5 の DSA の節はまるっと削られて以下の文章のみ掲載されている。

Prior versions of this standard specified the DSA. This standard no longer approves DSA for digital signature generation. DSA may be used to verify signatures generated prior to the implementation date of this standard. See FIPS 186-4 [20] for the specifications for DSA.

via FIPS 186-5 (Draft), Digital Signature Standard (DSS)

鍵長の問題（現在は鍵長を変数化することで対処している）以外はアルゴリズム自体に危殆化問題があるわけではないと思うが，出自がアレだし実装面の複雑さ¹ もあって評判がよろしくないのは聞いていた。まぁ「設計限界」というやつなんだろう。

その代わりといってはナニだが楕円曲線暗号のひとつである EdDSA (楕円曲線 ed25519/ed488) が FIPS 186-5 から電子署名標準のひとつとして加わることになっている。これについては以前に記事を書いた（なんでそのときに DSA に気がつかなかったのか）。

Edwards-curve Digital Signature Algorithm

まぁ，時代は楕円曲線暗号ということなのだろう。次期 OpenPGP である RFC 4880bis が正式にリリースされるタイミングでメインの鍵を替えようかと目論んでいるのだが，前倒ししたほうがいいのかねぇ。

ブックマーク

crypto/dsa: deprecate and remove from crypto/x509 and x/crypto/ssh · Issue #40337 · golang/go · GitHub
Cryptography Dispatches: DSA Is Past Its Prime
そろそろ GnuPG でも ECC を標準で使うのがいいんじゃないかな
Go 1.16 がリリースされた： Go 1.16 では crypto/dsa パッケージが非推奨になった。
NIST FIPS 186-5 および SP 800-186 正式版がリリースされた

参考図書

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

[Comment] SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

暗号化プライバシーを救った反乱者たち: スティーブン・レビー (著), 斉藤隆央 (翻訳); 紀伊國屋書店 2002-02-16; 単行本; 4314009071 (ASIN), 9784314009072 (EAN), 4314009071 (ISBN); 評価

[Comment] 20世紀末，暗号技術の世界で何があったのか。知りたかったらこちらを読むべし！

reviewed by Spiegel on 2015-03-09 (powered by PA-APIv5)

DSA は実装に必要な要素技術が多く，そのうちのひとつでも瑕疵があれば全体のセキュリティ強度が下がってしまう。 ↩︎

Authenticator と AAL

2020-09-27T10:45:38+00:00

どうも日本の金融界は「リスク感度が鈍い」そうなので，自衛のためにも2017年にリリースされた NIST SP 800-63-3 をベースに少しお勉強しておく。

SP 800-63-3 といえばパスワード運用で当時は話題になった。

「パスワードのベストプラクティス」が変わる

このパスワード話が出てくるのが SP 800-63B だが，このドキュメントでは Authenticator 全体について色々と書かれている。

Authenticator

Authenticator について適切な日本語が見当たらないが，強いて言うなら「認証機能」あるいは「認証器」といったところだろうか。たとえばパスワードも Authenticator だし，スマホにインストールした TOTP アプリも Authenticator だ。 Yubikey なんかの暗号デバイスも Authenticator に含まれる。

SP 800-63B では Authenticator を以下の9つに分類している。

種別名	認証要素
Memorized Secrets 記憶シークレット	知識
Look-Up Secrets ルックアップ・シークレット	所有
Out-of-Band Devices 経路外デバイス	所有
Single-Factor OTP Device 単要素 OTP デバイス	所有
Multi-Factor OTP Devices 多要素 OTP デバイス	所有＋知識／生体
Single-Factor Cryptographic Software 単要素暗号ソフトウェア	所有
Single-Factor Cryptographic Devices 単要素暗号デバイス	所有
Multi-Factor Cryptographic Software 多要素暗号ソフトウェア	所有＋知識／生体
Multi-Factor Cryptographic Devices 多要素暗号デバイス	所有＋知識／生体

また，各 Authenticator の例としては以下のものが挙げられる。

Authenticator	具体例
記憶シークレット	パスワード，PINコード
ルックアップ・シークレット	乱数表，認証失敗時のリカバリコード
経路外デバイス	SMS によるコード送信， QR コード（電子メールや VoIP は認められない）
単要素 OTP デバイス	アクティベーションを必要としない OTP デバイスまたはソフトウェア
多要素 OTP デバイス	アクティベーションを行った上で利用可能な OTP デバイスまたはソフトウェア
単要素暗号ソフトウェア	セキュアなストレージ上で保護されている暗号鍵
単要素暗号デバイス	FIDO U2F の USB ドングル
多要素暗号ソフトウェア	単要素暗号ソフトウェアに対して追加のアクティベーションを必要とするもの
多要素暗号デバイス	単要素暗号デバイスに対して追加のアクティベーションを必要とするもの

Authenticator Assurance Level

さらに SP 800-63B では AAL (Authenticator Assurance Level) を定義している。 AAL は 1 〜 3 の3段階あり，それぞれ以下に示す Authenticator の組み合わせを許容している。

AAL 1 では9種の Authenticator 全て許容され，単要素の認証で OK
AAL 2 では以下に示す通り複数の認証要素による多要素認証が必要：
- 多要素 OTP デバイス
- 多要素暗号ソフトウェア
- 多要素暗号デバイス
- 記憶シークレット＋以下
  - ルックアップ・シークレット
  - 経路外デバイス
  - 単要素 OTP デバイス
  - 単要素暗号ソフトウェア
  - 単要素暗号デバイス
AAL 3 では以下に示す通り，暗号鍵の所持証明要素とハードウェア関与を含む複数の認証要素による多要素認証が必要：
- 多要素暗号デバイス
- 単要素暗号デバイス＋記憶シークレット
- 多要素OTPデバイス(SW/HW)＋単要素暗号デバイス
- 多要素OTPデバイス(HW)＋単要素暗号ソフトウェア
- 単要素OTPデバイス(HW)＋多要素暗号ソフトウェア
- 単要素OTPデバイス(HW)＋単暗号ソフトウェア＋記憶シークレット

AAL の各レベルごとに要求されるセキュリティ事項（一部）は以下の通り。

要求事項	AAL 1	AAL 2	AAL 3
中間者攻撃耐性	必須	必須	必須
Verifier なりすまし耐性	不要	不要	必須
Verifier 改ざん耐性	不要	不要	必須
リプレイ耐性	不要	必須	必須
認証意図（AuthN Inbtent）	不要	推奨	必須
レコード保持ポリシー	必須	必須	必須
プライバシー統制	必須	必須	必須

金融系サービスの subscriber 確認で乗っ取りやなりすましを防ぎたいなら AAL 3 で何らかの物理暗号デバイスが必要だと思うけどねー。

格子型の乱数表は NG

現在は使ってるところはないだろうが，かつてネットバンキングでよく見られた格子型の乱数表はルックアップ・シークレットとしても NG だそうだ。まぁ，当然だよな。

SMS 認証は非推奨？

NIST は SMS によるコード送信について， SP 800-63-3 のドラフト段階では非推奨にするつもりだったらしい。

SMSを使った二要素認証を非推奨〜禁止へ、米国立技術規格研究所NISTの新ガイダンス案 | TechCrunch Japan

しかしその後，激しい議論があったようで，最終的には “RESTRICTED Authenticator” という位置づけまで緩和されたようだ。

Currently, authenticators leveraging the public switched telephone network, including phone- and Short Message Service (SMS)-based one-time passwords (OTPs) are restricted. Other authenticator types may be added as additional threats emerge. Note that, among other requirements, even when using phone- and SMS-based OTPs, the agency also has to verify that the OTP is being directed to a phone and not an IP address, such as with VoIP, as these accounts are not typically protected with multi-factor authentication.

via NIST SP 800-63 Digital Identity Guidelines-FAQ

（スマホを含む）電話機に依存した認証は，プライバシーも絡めて考えると筋が悪い。ぶっちゃけ SMS 認証を含む経路外デバイスを使った認証は排除するか（ルックアップ・シークレットのように）優先順位を下げて非常時のみ使えるようにするのがいいと思う。もちろん電話番号を広告に流用するなど以っての外である。

生体情報は Authenticator として使えるか

Authenticator の分類を見れば分かるように，生体情報は単独では認証手段としては使えないという認識のようだ。そもそも生体情報は秘密情報ではないのだから当たり前といえば当たり前かな。

ブックマーク

参考図書

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

信頼と裏切りの社会: ブルース・シュナイアー (著), 山形浩生 (翻訳); NTT出版 2013-12-24; 単行本（ソフトカバー）; 4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (ISBN); 評価

[Comment] 社会における「信頼」とは。

reviewed by Spiegel on 2015-11-28 (powered by PA-APIv5)

NIST SP 800-207: “Zero Trust Architecture”

2020-09-17T03:25:07+00:00

毎度の言い訳だが（笑），私がネットワーク管理者でセキュリティ管理者だったのは遥か昔の牧歌的な時代であり，現在時点で参加・所属する企業・組織のポリシーについてどうこう言う権限はないし，その気もない。ただし，自衛のための知識を摂取し続けることは必要だと思っている。

というわけで，今回は2020年8月に最終版が公開された NIST SP 800-207 の触りの部分を覚え書きとして記しておく。

Zero Trust および Zero Trust Architecture の定義

SP 800-207 では Zero Trust および Zero Trust Architecture は以下のように定義づけられている。

Zero trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. Zero trust architecture (ZTA) is an enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a zero trust enterpriseis the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a zero trust architecture plan.

via SP 800-207: Zero Trust Architecture

ポイントは，アクセスを行うリソース，権限，期間が最小となるよう設計することだ。これは，特定の安全地帯に入る許可さえあれば，内部のリソースにラフにアクセスできる従来の境界型セキュリティ設計とは大きく異なっている。

ちなみに SP 800-207 では，アクセスする対象を resource と呼んでいる。これは単なるデータだけではなく物理的なデバイスも対象となっていることを示す。つまり (日本では既に幻滅期に入っている) IoT も視野に入っているわけだ。

さらに SP 800-207 では，アクセスを行う主体を subjects と呼んでいる。そう呼ぶからには subjects が指すのは人間（ユーザ）だけではなく，アプリケーション，サービス，デバイス等も含まれる。また subjects は authorized and approved subjects と all other subjects で色分けされている。もちろん all other subjects の代表は「攻撃者（attackers）」である。

つまり，あるリソースに対して認証・承認されない actor は，システム上の役割に関わらず，全て敵である（笑）この辺が「ゼロトラスト」と呼ばれる所以なのだろう。

ZT/ZTA が重視される理由としては以下の2つが挙げられると思う。

企業・組織への攻撃が巧妙化していて，セキュリティ管理の比重が防御から監視へシフトした
クラウド上の XaaS リソースは「境界型」では管理できない

できれば安直にクラウドに繋がろうとするスマート家電もなんとかしてほしいのだが…

Zero Trust Architecture の基本理念

SP 800-207 では ZTA の基本理念として，以下の7つの項目を挙げている。

All data sources and computing services are considered resources.

All communication is secured regardless of network location.

Access to individual enterprise resources is granted on a per-session basis.

Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes.

The enterprise monitors and measures the integrity and security posture of all owned and associated assets.

All resource authentication and authorization are dynamic and strictly enforced before access is allowed.

The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.

via SP 800-207: Zero Trust Architecture

ちなみに日本語訳は以下の通り。

すべてのデータソースとコンピューティングサービスをリソースとみなす

ネットワークの場所に関係なく、すべての通信を保護する

企業リソースへのアクセスは、セッション単位で付与する

リソースへのアクセスは、クライアントアイデンティティ、アプリケーション/サービス、リクエストする資産の状態、その他の行動属性や環境属性を含めた動的ポリシーにより決定する

すべての資産の整合性とセキュリティ動作を監視し、測定する

すべてのリソースの認証と認可を動的に行い、アクセスが許可される前に厳格に実施する

資産、ネットワークインフラストラクチャ、通信の現状について可能な限り多くの情報を収集し、セキュリティ態勢の改善に利用する

NIST SP800-207 「ゼロトラスト・アーキテクチャ」の解説と日本語訳 | PwC Japanグループより

面白いのは ZTA に最初から「監視」が組み込まれていること，常に状況をフィードバックして「改善」のサイクルを構築するところまでがセットになっていることだろう。

セキュリティに於いても PDCA サイクル，いや今なら OODA ループか，が重要ということやね（笑）

大変なのは…

ZT を組み込むこと自体は，そう難しくないだろう。おそらくは既存のシステムに ZT の仕組みをラッピングすることで構成可能なはずだ。

via SP 800-207: Zero Trust Architecture

大変なのは ZTA におけるリソースとサブジェクト（の権限）の定義・運用・評価だろう。これ，かなり細かい要求分析が必要だと思うよ。

当然ながら人間組織の役職で権限を決めるわけにはいかない。システム管理者やセキュリティ管理者（セキュリティ企業も含めて）であっても「アクセスしてはいけないリソース」はある。サブジェクトやリソースの杜撰な管理で Class Break を引き起こした Twitter の事例は耳に新しいだろう。日本での最近の Class Break 事例は「ドコモロ系事案¹」か（笑）

だからこそループを回して「改善」していかなければならないんだろうけど。 Refactoring することを前提としたシステム設計が大事。

ブックマーク

参考図書

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

信頼と裏切りの社会: ブルース・シュナイアー (著), 山形浩生 (翻訳); NTT出版 2013-12-24; 単行本（ソフトカバー）; 4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (ISBN); 評価

[Comment] 社会における「信頼」とは。

reviewed by Spiegel on 2015-11-28 (powered by PA-APIv5)

ＯＯＤＡ　ＬＯＯＰ（ウーダループ）―次世代の最強組織に進化する意思決定スキル: チェットリチャーズ (著), 原田勉 (翻訳); 東洋経済新報社 2019-02-22 (Release 2019-02-22); Kindle版; B07ND6QTN4 (ASIN)

[Comment] 買ったはいいが，実はまだ読んでない。

reviewed by Spiegel on 2019-07-02 (powered by PA-APIv5)

キャッシュレス決済を使った不正利用に関する一連のインシデントのこと。 Facebook の TL で見かけた「ドコモロ系事案」のフレーズが面白かったので使ってみた（笑） ↩︎

Edwards-curve Digital Signature Algorithm

2020-06-07T08:33:37+00:00

ネットであちこち眺めていて気がついたのだが SP 800-57 第一部の Rev.5 最終版が2020年5月にリリースされていた。

SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1 – General | CSRC

私はセキュリティや暗号技術の専門家ではないし Rev.5 の変更点が（軽微なものも合わせて）67項目もあって全部は紹介しきれないので，ひとつだけ

In Section 2.2, EdDSA was added. Modified ECDSA.

via SP 800-57 Part 1 Revision 5

について関連情報を覚え書きの形で記しておく。

RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)

EdDSA のオリジナルは2011年に公開された “High-speed high-security signatures ” らしい。その後も改良版が出たり色々あって，2017年に RFC 8032 として標準化された。

EdDSA は以下の特徴を持っている。

EdDSA provides high performance on a variety of platforms;

The use of a unique random number for each signature is not required;

It is more resilient to side-channel attacks;

EdDSA uses small public keys (32 or 57 bytes) and signatures (64 or 114 bytes) for Ed25519 and Ed448, respectively;

The formulas are “complete”, i.e., they are valid for all points on the curve, with no exceptions. This obviates the need for EdDSA to perform expensive point validation on untrusted public values; and

EdDSA provides collision resilience, meaning that hash-function collisions do not break this system (only holds for PureEdDSA).

via RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)

特に2番目が重要。

これまでの NIST 標準の（ECDSA を含む） DSA は署名の度にランダムな値をひとつ決めないといけないのだが，ここの実装をサボると，最悪の場合，秘密鍵の漏洩に繋がる。更に言うと，かつて SP 800-90A に載っていた疑似乱数生成器 Dual_EC_DRBG に NSA の関与が疑われる欠陥が発覚し SP 800-90A を改訂する騒ぎにまで発展したこともある。

このように DSA の具体的な実装について常に懸念が付きまとっているため，より安全性が高いとされる EdDSA が注目されることとなった¹。

EdDSA で使える楕円曲線にはかなりのバリエーションがあるのだが， RFC 8032 に記載されているのは以下の2つである²。

楕円曲線名	鍵長（bytes）	強度（bits）
edwards25519	32	128
edwards448	57	224

生成した ECC 鍵を2031年以降も使い続けるにはセキュリティ強度にして128ビット以上必要だが，この2つの楕円曲線であれば十分であることが分かる。

NIST 標準としての EdDSA

EdDSA の RFC 化に伴い，以下の NIST 標準文書にも EdDSA が追加されることになった。ただし今のところはまだドラフト版である。

ちなみに両方共パブリックコメントは2020年初に締め切られている。

FIPS 186-5 および SP 800-186 が正式リリースされれば，政府調達でもなんでも，大手を振って EdDSA を使えるようになる（笑）

【2023-02-04 追記】 FIPS 186-5 および SP 800-186 正式版がリリースされた

EdDSA の実装

OpenPGP と GnuPG

OpenPGP は RFC 6637 で正式に ECC を組み込んだが，この中に EdDSA は含まれていない。ただし，次期 OpenPGP となる RFC 4880bis では EdDSA を組み込み済みで GnuPG の最新版では既に EdDSA 鍵を生成し使用することができる。

そろそろ GnuPG でも ECC を標準で使うのがいいんじゃないかな

なお，最新の GnuPG では edwards25519 のみサポートしているようだ。

OpenSSH

OpenSSH では EdDSA/edwards25519 鍵を生成・使用できる。鍵生成は

$ ssh-keygen -t ed25519

で可能。

OpenSSL

現在の OpenSSL は EdDSA をサポートしている。 edwards25519 および edwards448 を指定可能。

【おまけ】量子コンピュータ耐性

現在，公開鍵暗号の主流である IFC (Integer Factorization Cryptosystems) および FFC (Finite Field Cryptosystems) の各アルゴリズムは量子コンピュータによる攻略法が既にあり，十分な性能を獲得すれば短時間で攻略可能になると考えられている。 ECC も FFC のバリエーションであり，これに含まれる。

しかし，2020年時点の性能では128ビット以上のセキュリティ強度であれば現実的な脅威には至っていないようだ。

例えば、量子コンピュータを用いて2048ビットRSA合成数の素因数分解を行う場合には、量子誤りが一切ないという理想的な環境下でも、4098量子ビットが必要であり、1012～1013回のゲート演算が必要であると見積もられています。また、量子誤りがあるという現実的な環境下では、2000万量子ビットが必要であるという見積もりもあります。

現在の量子コンピュータによる暗号技術の安全性への影響より

量子コンピュータの性能を測る上での指標（量子ビット数、量子誤りの大きさ、演算可能回数など）や、量子コンピュータの開発状況もあわせて考慮にいれると、近い将来に、2048ビットの素因数分解や256ビットの楕円曲線上の離散対数問題が解かれる可能性は低いと考えます。

現在の量子コンピュータによる暗号技術の安全性への影響より

ただし，量子コンピュータ開発は成長が著しい分野でもあり，今後も成り行きを注視していく必要がある。

【おまけ2】 CRYPTREC による EdDSA の評価

2021年に公開された「CRYPTREC Report 2020」に EdDSA に対する評価が載っていたので紹介する。

難しい話はすっ飛ばして総評だけつまみ食いすると

総評：下記の観点から、EdDSA の構成に関わる安全性において、EdDSA が ECDSA に劣ると考えられる点は無いと思われると述べている。

Schnorr 署名をもとに EdDSA は構成されているため、ランダムオラクルモデルで安全性が証明されている Schnorr 署名に対する安全性評価を参考にすることができる。

Schnorr 署名との大きな違いはノンスの生成方法であるが、EdDSA におけるノンスの生成方法は、署名の内部乱数を弱い疑似乱数生成器に委ねることによる危険を排除し、現実的な脅威を回避するための配慮が施されている。

比較対象となる ECDSA については、既存結果として generic group model でのみ安全性が証明されている。

CRYPTREC Report 2020 暗号技術評価委員会報告より

とのこと。ノンスの評価やサイドチャネル攻撃耐性など具体的な話は本文を参照のこと。

ブックマーク

参考図書

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

[Comment] SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

DSA に対する懸念は，実装に必要な技術要素が多すぎる点にあるかもしれない。如何にシンプルな設計で要件を満たすかってのは安全性を考える上でも重要であるというよい事例になっていると思う。 ↩︎
edwards25519 は Curve25519 と双有理同値である。ちなみに Curve25519 は ECDH 用の楕円曲線およびそのライブラリで，公有（public domain）のソフトウェアとして公開されている。 ↩︎

「パスワードのベストプラクティス」が変わる

2017-10-16T10:21:02+00:00

Bruce Schneier 氏の “Changes in Password Best Practices” の内容が簡潔だったので「そのうち紹介しなくちゃ」と思っていたが，先を越されたっぽい感じなので，便乗記事として上げておく（笑）

やばいパスワード - 複雑なパスワードを強制、でも破られやすいという現実：ITpro

まずは “Changes in Password Best Practices” で挙げられている3つの要件を以下に紹介する。

Stop it with the annoying password complexity rules. They make passwords harder to remember. They increase errors because artificially complex passwords are harder to type in. And they don’t help that much. It’s better to allow people to use pass phrases.
top it with password expiration. That was an old idea for an old way we used computers. Today, don’t make people change their passwords unless there’s indication of compromise.
Let people use password managers. This is how we deal with all the passwords we need.

強調部分は私によるものである。

生成規則が複雑なだけのパスワードではダメ

最初の要件は，いたずらに複雑なパスワード生成規則を強要するな，というものだ。ここで勘違いしてもらっては困るのだが，これは「複雑なパスワードはダメ」と言っているのではない。

パスワードの要件は

できるだけ文字数が多いこと
出来るだけ文字種が多いこと
出来るだけランダムに文字を選ぶこと

の3つである。これを人力で作って覚えるのは難しい。

パスワードの強度に関して IPA が2013年に発表した資料がある。

情報漏えいを防ぐためのモバイルデバイス等設定マニュアル：IPA 独立行政法人情報処理推進機構
- 情報漏えいを防ぐためのモバイルデバイス等設定マニュアル解説編

このうちの「解説編」にパスワードの解読されやすさの一覧表がある。以下に引用しよう。

利用する文字種類数と内訳				パスワード長
種類数	数字	文字	シンボル	4文字	8文字	12文字	16文字
10種	0-9	なし	なし	1円未満（$2^{13.3}$）	1円未満（$2^{26.6}$）	約35円（$2^{39.9}$）	約35万円（$2^{53.2}$）
36種	0-9	a-z	なし	1円未満（$2^{20.7}$）	約100円（$2^{41.4}$）	約1.65億円（$2^{62.0}$）	約276兆円（$2^{82.7}$）
62種	0-9	a-z A-Z	なし	1円未満（$2^{23.8}$）	約7,500円（$2^{47.6}$）	約1,120億円（$2^{71.5}$）	約165京円（$2^{95.3}$）
94種	0-9	a-z A-Z	! " # $ % & ' ( ) = ~ \| - ^ ` ¥ { @ [ + * ] ; : } < > ? _ , . /	1円未満（$2^{26.2}$）	約21万円（$2^{52.4}$）	約16.5兆円（$2^{78.7}$）	約129,000京円（$2^{104.9}$）

パスワード解読の想定コスト例（情報漏えいを防ぐためのモバイルデバイス等設定マニュアル解説編 2.4.2.2項より）

見たらわかると思うが，文字種の多さより文字数の多いほうがインパクトがあることが分かる。数英大小文字記号すべて使って8文字のパスワードを作っても1日で解読完了させるコストは21万円ほどだが，これは数字だけで16文字からなるパスワードよりもコストが低い。

ただしこれは最もコストの高い「総当たり攻撃」の場合である（しかも4年も前の話だ）。

利用できる文字種類すべてを完全にランダムに選択して作ったパスワードを一つ一つ調べる全数探索により1日で解読しようとした際にかかるおおまかな想定攻撃コストを示しています。ここでは、全数探索(暗号鍵の総数256)でDES10を1日で解読するためのコストを約250万円と仮定します。また、パスワードを1つ検査するのとDESの暗号鍵を1つ検査するコストは同じであるとし、パスワードを求めるのに必要な計算量(検査する個数)が半分になればコストも半分、2倍になればコストも2倍になるものとしています。

情報漏えいを防ぐためのモバイルデバイス等設定マニュアル解説編 2.4.2.2項より

したがって辞書にあるような単語を組み合わせたパスフレーズの場合は，余程の単語数が必要になる。たとえば「やばいパスワード」で紹介されている方法では

テレビは1日1時間 → Terebi ha 1 niti 1 Jikan  → Terebiha1niti1Jikan

といった感じで19文字のパスワードを生成していて，先程の表で照らし合わせると，総当たり攻撃なら，ほとんど天文学的なコストになるが，実際にはそれぞれの単語が攻撃側の辞書にある場合は，たったの6単語しかないわけで，やり方によっては解読コストをかなり引き下げられる可能性もある（犯罪者側の最近の事情をよく知らないので杞憂かもしれないが）。

パスフレーズというのは，もともと「辞書攻撃」などない長閑な時代に PGP などのセキュリティ製品に採用されていたもので（今でも GnuPG ではパスフレーズが使用できる）

I could tell you my pass phrase, but then I would have to kill you.

みたいな比較的長い文（phrase）を使うことを想定している¹。したがってパスワード解読技術が向上している今の時代に単語を組み合わせただけのパスフレーズがどこまで効果的かは正直に言って分からない。しかし “Password!1” みたいな「法令遵守の観点から社内規則に則ってはいるけど機械で容易に推測可能なパスワード」よりは遥かにマシということなのである。

パスワードの有効期限など無意味

2番目の要件は既に散々言われていることなので今更であろう。

週末スペシャル：「パスワードの定期変更はすべきでない」，他

【追記】パスワード定期変更の起源？

「JNSAメールマガジン　臨時号　2015.4.3.」によると

パスワードの定期的な変更は、パスワード文字列が4文字だった時代にパスワードの総当たり攻撃(ブルートフォース攻撃)の対策として実施したことが起源と言われている。

JNSAメールマガジン　臨時号　2015.4.3.より

なんだそうだ。ホンマかいな（笑）

むしろ，ネットワーク管理者やセキュリティ管理者が自分たちの仕事（アカウント管理）を面倒臭がって「放っておいても期限切れになる」パスワード運用を強制した，のほうに1票いれるよ。

パスワード管理ツールを使え

3番目の要件もおなじみのやつである。

最近はウイルス対策ソフトを提供しているセキュリティ企業がパスワード管理ツールも提供していたりするので，そちらを使う手もある。私としては KeePass を是非オススメするが。

KeePass Password Safe

KeePass はオープンソースのパスワード管理ツールで Windows の .NET Framework 用だが Linux 用に Mono で動作するバージョンも存在する。また Android や iOS で動作する互換アプリも存在する。

Keepass2Android Password Safe - Google Play

パスワード管理ツールにはデータ暗号化にマスタパスワードを要求するものが多いが， KeePass では暗号鍵ファイルで暗号化できるのでマスタパスワードも不要だ（マスタパスワードと組み合わせることも可能）。暗号鍵ファイルさえ適切に管理すればパスワードを格納した DB ファイルをクラウドに置いて（他人に見えないところに置いてね）機器間で共有することもできる。

パスワードを覚えようとか考えないこと

いつも言っていることだが「パスワードを覚えるなんて脳みその無駄使い」である。最初に述べた3要件を満たすパスワードをツールで生成させてツールで管理すればよい。どうしても不安ならば紙に書いて誰にも知られないように管理する手もある。パスフレーズだって「覚えないといけない」という点では同じことなのだ。

「セキュリティと利便性のトレードオフ」なんてのは昔の話である。適切な運用をすればセキュリティも利便性も両方確保できる。それをしないのは単なる怠慢だ。

ブックマーク

参考図書

PGP―暗号メールと電子署名: シムソンガーフィンケル (著), Garfinkel,Simson (原著), ユニテック (翻訳); オライリー・ジャパン 1996-04-01; 単行本; 4900900028 (ASIN), 9784900900028 (EAN), 4900900028 (ISBN); 評価

[Comment] 良書なのだが，残念ながら内容が古すぎた。 PGP の歴史資料として読むならいいかもしれない。

reviewed by Spiegel on 2014-10-16 (powered by PA-APIv5)

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

[Comment] SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

この物騒なパスフレーズは Simson Garfinkel 氏の『PGP』に載っていたものである。パスフレーズは文字数や文字種の制限がないのが特徴である。もし入力に日本語（UTF-8）が使えるのなら，海外の犯罪者に対しては，かなり強力なパスフレーズができると思うんだけどねぇ。 ↩︎

NIST SP800-52 Rev.1 の邦訳が登場

2017-02-01T14:06:06+00:00

IPA は NIST のセキュリティ関連文書の邦訳を積極的に行っているが，SP800-52 Rev.1 の邦訳が登場したようだ。

古い話になるが，2013年までに RC4 の危殆化や SSL/TLS の攻略コードがいくつか「開発」されたことにより TLS 1.2 への移行が強く推奨されることになった。それを受けての SP800-52 改訂だったのだが，その後の SSL/TLS やその実装である OpenSSL 等のソフトウェアへの攻撃の激しさはみなさんご存じのとおりである。

そうそう。 IPA と言えば最近になってヤバい注意喚起が上がっている。

【注意喚起】SQLインジェクションをはじめとしたウェブサイトの脆弱性の再点検と速やかな改修を：IPA 独立行政法人情報処理推進機構

また2014年に大騒ぎになった Heartbleed 脆弱性をいまだに放置しているサイトもあるようだ。

「Heartbleed」脆弱性、多くのサイトやサーバでいまだに存在–Shodan Report - ZDNet Japan

攻撃者は既知の攻撃は当然のように試す。先延ばししていいことは何もない。いや，マジでお願いしますよ，サイト運用者の方々。

ブックマーク

参考図書

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

[Comment] SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

List of Nist [text.Baldanders.info]

NIST SP 800-63-4 最終版がリリース

ブックマーク

参考図書

誰が「パスワードは複雑なものにしろ」と言ったのか

ブックマーク

参考図書

NIST FIPS 186-5 および SP 800-186 正式版がリリースされた

DSA が標準から外れる

ECDSA 自体を定義し直す

EdDSA が標準として承認された

ブックマーク

参考図書

それはワンタイム・パスワードの問題ではない

参考図書

DSA は NIST 電子署名標準から外れるようだ

ブックマーク

参考図書

Authenticator と AAL

Authenticator

Authenticator Assurance Level

格子型の乱数表は NG

SMS 認証は非推奨？

生体情報は Authenticator として使えるか

ブックマーク

参考図書

NIST SP 800-207: “Zero Trust Architecture”

Zero Trust および Zero Trust Architecture の定義

Zero Trust Architecture の基本理念

大変なのは…

ブックマーク

参考図書

Edwards-curve Digital Signature Algorithm

RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)

NIST 標準としての EdDSA

EdDSA の実装

OpenPGP と GnuPG

OpenSSH

OpenSSL

【おまけ】 量子コンピュータ耐性

【おまけ2】 CRYPTREC による EdDSA の評価

ブックマーク

参考図書

「パスワードのベストプラクティス」が変わる

生成規則が複雑なだけのパスワードではダメ

パスワードの有効期限など無意味

【追記】 パスワード定期変更の起源？

パスワード管理ツールを使え

パスワードを覚えようとか考えないこと

ブックマーク

参考図書

NIST SP800-52 Rev.1 の邦訳が登場

ブックマーク

参考図書

【おまけ】量子コンピュータ耐性

【追記】パスワード定期変更の起源？