正式な検証は、安全でエラーのないコードをどのように保証しますか？
私は、コードの数学モデルを構築することによってコードが正式に検証されたことを読みました。次に、このモデルが特定の要件を満たしていることを実証するための正式な証明が提供されています。正式な検証では、結果のコードに脆弱性がないことをどのように保証しますか？
コードに脆弱性がないことを保証するものではありません。ただし、検証を適切に使用すると、アプリケーションが安全であるという保証（信頼度）を高めることができます。
非常に広い観点から言えば、この問題には2つの側面があります。
検証。システムの数学モデルと要件の数学仕様が与えられた場合、システムは仕様を満たしますか？
検証。right要件のセットはありますか？数学的仕様は真の要件を正確に反映していますか？数学モデルはコードに正確かつ完全に対応していますか？
検証にのみ焦点を当てる人もいますが、どちらも重要です。
あなたの状況では、if仕様には関連するすべてのセキュリティ要件が組み込まれており、if数学モデルがコードに正しく対応し、if検証が適切に実行されて成功した場合、 mayは、システムが私たちのセキュリティ要件を満たすことを大幅に保証するための基礎を持っています。
最良のケースでは、検証は、セキュリティを保証するための強力なツールとなり得ます。ただし、他と同様に、適切に使用しないと、テクノロジーを誤用したり、誤った安心感を得たりする可能性があります。最も一般的な障害モードの1つは、検証プロセスが関連するすべてのセキュリティ要件を検証しないことです（見落とされたり、省略されたりする）。
さらに多くのことを言うには、システムの詳細、セキュリティ要件、および実行された検証の性質を掘り下げる必要があるかもしれませんが、うまくいけば、これで概要がわかります。
正式な検証は安全なシステムを保証するものではありません。安全なシステムを保証するものは何もありません。正式な検証でできることは、システムの一部が安全であるという非常に高い保証を提供することです。
形式的な検証は、特定の仮定の下で、システムのモデルに特定の特性があることを数学的に証明します。したがって、システムの一部が正式に検証されている場合でも、システムが安全であるためにはいくつかの条件が残っています。
- 検証の基礎となる前提条件は満たされていますか？
- システムは検証済みのモデルと一致していますか？
- 検証システムによって与えられた証明は正しいですか？
- 実証済みの特性はシステムのセキュリティを確保するのに十分ですか？
正式な検証の範囲は大きく異なります。たとえば、 バッファオーバーフロー （一般的な種類の脆弱性）は簡単に発見できます。CまたはC++よりも高レベルのほとんどの言語では、コンパイルされたプログラムでバッファオーバーフローが発生しないことが保証されています。それにもかかわらず、コンパイラーが壊れたコードの通過を許可している可能性があります。コンパイラーのバグはプログラムのバグよりもまれですが、不可能ではありません。ただし、バッファオーバーフローは1種類にすぎません。ほとんどのシステムのセキュリティは、バッファオーバーフローがないことを知ることよりもはるかに重要です。 （関連資料： メモリ容量にメモリの内容があるかどうかコンピュータがチェックしないのはなぜですか？ ）
上記の制限を説明するために、具体的な例を見てみましょう。一部の スマートカードJavaカード 仮想マシンを実行し、 検証済み であるバイトコードのみを実行します。バイトコードベリファイアは、原則として、コードが割り当てられたメモリ空間の外を覗いたり、突いたりできないことを保証します。これにより、すべてではなく一部の脆弱性が回避されます。
- 検証では、バイトコードインタープリターがその仕様に従って動作する場合にのみ、そのプロパティが保証されます。さらに、ハードウェアがインタープリターを正しく実行しない場合、すべての賭けは無効になります（たとえば、スマートカードを攻撃する1つの方法は、一部の命令がスキップされる原因となる電源異常を引き起こすことです）。
- ベリファイアを経由せずにコードをアップロードできるバグがある場合、カードのコードに、検証によって保証されたプロパティがない可能性があります。
- ベリファイア自体にバグがあり、不正なコードがアップロードされる可能性があります。
- カード上のアプリケーションのコードが他のアプリケーションのメモリに直接アクセスしない場合でも、他の方法でスパイしたり、混乱させたりする可能性があります。たとえば、同じデバイスで実行されている他のコードのプロパティを推定するタイミングなどの サイドチャネル を悪用する可能性があります。
さらに、システムのセキュリティは、カード上のアプリケーション間の分離以外の事柄に依存する場合があります。たとえば、認証システムにより、攻撃者がカードを制御できる場合や、プロトコルレベルの脆弱性があり、攻撃者が通信を妨害できる場合などがあります。
高保証システムでは、正式な検証は2つの方法で役立ちます。
- コードが仕様に一致することを証明します。これには、実行環境の正式なモデル（ハードウェア、コンパイラーまたはインタープリター、標準ライブラリなど）と多くの作業が必要です。
- 仕様に特定の望ましい特性があることを証明します。これには、仕様の形式化、慎重なプロパティの選択、および多くの作業が必要です。
セキュリティ評価の Common Criteria は、いくつかの assurance level を定義します。最高の保証レベル（EAL7）のみが正式な検証を必要とします。これが唯一の要件ではありません。正式な検証は、ドキュメント、侵入テストなど、システムの他の側面の評価を妨げません。
形式的な検証は、システムが明確に定義されたドメイン、範囲、および関数の動作を定義する明確に理解されたルールを備えた一連の変換としてモデル化できる非常に制約された場合にのみ機能します-多くの場合、これは、数学モデルをソフトウェアで実現したシステム、または（比較的:-)）システムの動作からモデルを簡単に導出できるシステム（汎用CPUよりも複雑さが大幅に少ないデジタル回路）
私は80年代にこれまでの先駆者として働いていました。その努力は「確かに正しいコード」を生成することでした-私が思い出す1つのシステムはAdeleと呼ばれ、エイダで書かれたプログラムで動作しました。偶然にも、私たちは冗談でアデルを使用すると、書くのに10倍の時間がかかり、実行速度が10倍遅くなり、10％しかクラッシュしなかったと言っていました-エッフェルに関するバートランドマイヤーの著述を見てみたいと思うかもしれません。言語が前提条件、事後条件、不変条件、および私が忘れてしまった他の束を介して内部検証チェックを提供する方法に関する重要な考えと努力.
検証では、システムに指定されたプロパティがあるかどうかを確認します。プロパティは、さまざまな表記法とロジックで表現される場合があります。これらのプロパティを指定することは困難です。したがって、設計者がセキュリティの考えを検証に適した正式な表記法で表現でき、ソフトウェアがその特性を満たしていることが証明されれば、それは安全です。現実には、汎用ハードウェアで実行されている実際のソフトウェアの重要なプロパティを検証することはほとんど不可能です。
任意の脆弱性は広義の用語です。正式な検証（実際には、アルゴリズム/システムが特定のプロパティを持っていることの自動化された証明）が特定の脅威に向けられているためです。データの漏洩、防御を介した外部情報の浸透、メモリリーク、割り当ての失敗、スタックオーバーフローなど。この点に関する現在の作業のプレビューについては、たとえば、訪問 Software Engineering Institute カーネギーメロンユニ。
形式的な検証では、指定された仕様へのコーディングの適合のみをチェックします。仕様自体が不適切/正しくない場合、最終的な検証は明らかに価値がありません。正式な検証については、例を参照してください。 http://en.wikipedia.org/wiki/Formal_verification および http://en.wikipedia.org/wiki/Isabelle_%28proof_assistant%29