oddmakeの日記: Paul Kocher(6) 1
眠いときやった翻訳はよれよれになるという。
…戦慄を禁じえないが訳出する。
8) How do you think?
どう思います?
by Charles Dodgeson
Charles Dodgesonの質問
When I first read about some discovery of a weakness (for example, I know your name from your work on MD5), I am always struck by the thinking beyond the framework of the designer of the system and of the community to date. The same things strikes me about timing attacks and similar sorts of things. These are things that I wouldn't have thought of in a million years. Can you give any insight into how minds like yours work. And to what extent you think that this might be a trainable skill.
私が最初にある脆弱性の発見(例えば、私はあなたの名前をあなたの仕事のMD5から知っています)について読んだときから、私はつねにシステムの設計者やその時点でのコミュニティの枠組みを超える発想に衝撃を受けています。同じ衝撃をTiming攻撃やそれに似たようなことについても受けています。私が百万年かかっても思いつかないことがあるのです。私にあなたのような精神がいかに働くかについて、そしてこれがどこまで訓練可能な技術であるか何か教えてくれませんか。
I normally hate the cliche of "thinking outside of the box", but here it is fully appropriate.
私はふつうは、「枠にはまらない考え方」という決まり文句が嫌いです。でもここでは完璧にあてはまると思います。
Paul:
Security work requires understanding systems at multiple levels. For example, differential power analysis involves transistor-level properties affecting logic units affecting microcode affecting CPUs affecting crypto algorithms affecting protocols affecting business requirements. For engineers who are used to working at only a single layer, security results often seem surprising. Broad experience is also important because the vast majority of security problems involve unintended interactions between areas designed by different people.
セキュリティの仕事は複数のレベルでシステムを理解することが必要です。例えば、差分攻撃法はトランジスタレベルの特性が論理回路に影響しそれがマイクロコードに影響しそれがCPUに影響しそれは暗号アルゴリズムに影響しそれがプロトコルに影響しそれがビジネスの要求に影響するのです。単一のレイヤで仕事をするのに慣れたエンジニアにとってセキュリティ分析の結果はしばしば驚くべきものに見えます。とても大多数のセキュリティ問題が異なる人々によって設計された領域同士の意外な相互作用が関わっているため、幅広い経験も重要です。
Two specific subjects that I think are often neglected are low-level programming and statistics. These are essential to understand how things actually work and to assess the likelihood that systems will fail. A skeptical mindset is also important. Try to assume things are bad until you are convinced otherwise.
私がしばしば無視されていると思う二つの事柄が、低レベルのプログラミングと統計だ。
これはいかにモノが実際に働くかということを理解し、システムが故障する可能性を評価するのに必須だ。懐疑的な意識も重要だ。あなたが納得するまで、物事は悪いと考えるようにしてみなさい。Some specific questions that are helpful to ask include:
問いかけに役立つ質問は次のようなものがある:
What information and capabilities are available to attackers?
What information and capabilities are available to attackers?
What esoteric corner cases has nobody studied carefully?
How would a lazy or inexperienced designer have designed the system?
What states can each participant be in?
Where is the most complexity in the security perimeter? (Complex parts are the most likely to fail.)
What unwritten assumptions are being made, and are they correct?
If you aren't sure how to begin an evaluation, consider sketching out how you would have done the design. You can then compare your design against the target. The differences often reveal mistakes you made (a great way to learn) or identify problems with the target system.どんな情報や能力を攻撃者は利用することができるか?
どんな角に隠れた誰もまだ調べていない秘密があるだろうか?
システムを設計したのどんな怠惰あるいは未熟な設計者だろうか?
利用者はどんな状態であるだろうか?
どこがセキュリティ防衛線のもっとも複雑な部分だろうか?(複雑な部品はもっとも故障しやすい)
どんな明記されない仮定がなされているだろうか、そしてそれは正しいか?
もし君が評価をどうはじめていいか不確かな時には、どのように君が設計するのかスケッチするのを考えてみたまえ。君はそれから君の設計と目標とを比較することができる。違いはたいてい君のやった間違いを明らかにする(学ぶのには良い方法だ)あるいは目標のシステムの問題点を同定する。
続きはまた。
あと2つ (スコア:2)