tpm2-tss

本サイトが提示する下記のベストプラクティスを実行するプロジェクトは、Open Source Security Foundation (OpenSSF) バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。

これがあなたのプロジェクトなら、あなたのプロジェクトページにあなたのバッジステータスを表示してください！バッジステータスは次のようになります。 プロジェクト 2332 のバッジ レベルは passing です バッジステータスの埋め込み方法は次のとおりです。

これらは合格レベルの基準です。シルバーまたはゴールドレベル基準を表示することもできます。

        

 基本的情報 13/13 ●

  • 識別情報

    This repository hosts source code implementing the Trusted Computing Group's (TCG) TPM2 Software Stack (TSS). This stack consists of the following layers from top to bottom:

    • Feature API (FAPI) as described in the TCG Feature API (FAPI) Specification along with TCG TSS 2.0 JSON Data Types and Policy Language Specification This API is designed to be very high-level API, intended to make programming with the TPM as simple as possible. The API functions are exposed through a single library: libtss2-fapi.
    • Enhanced System API (ESAPI) as described in the TCG TSS 2.0 Enhanced System API (ESAPI) Specification This API is a 1-to-1 mapping of the TPM2 commands documented in Part 3 of the TPM2 specification. Additionally there are asynchronous versions of each command. In addition to SAPI, the ESAPI performs tracking of meta data for TPM object and automatic calculation of session based authorization and encryption values. Both the synchronous and asynchronous API are exposed through a single library: libtss2-esys.
    • System API (SAPI) as described in the TCG TSS 2.0 System Level API (SAPI) Specification This API is a 1-to-1 mapping of the TPM2 commands documented in Part 3 of the TPM2 specification. Additionally there are asynchronous versions of each command. These asynchronous variants may be useful for integration into event-driven programming environments. Both the synchronous and asynchronous API are exposed through a single library: libtss2-sys.
    • Marshaling/Unmarshaling (MU) as described in the TCG TSS 2.0 Marshaling/Unmarshaling API Specification This API provides a set of marshaling and unmarshaling functions for all data types define by the TPM library specification. The Marshaling/Unmarshaling API is exposed through a library called libtss2-mu.
    • TPM Command Transmission Interface (TCTI) as described in the TCG TSS 2.0 TPM Command Transmission Interface (TCTI) API Specification. This API provides a standard interface to transmit / receive TPM command / response buffers. It is expected that any number of libraries implementing the TCTI API will be implemented as a way to abstract various platform specific IPC mechanisms. Currently this repository provides several TCTI implementations: libtss2-tcti-device, libtss2-tcti-tbs (for Windows), libtss2-tcti-swtpm and libtss2-tcti-mssim. The former should be used for direct access to the TPM through the Linux kernel driver. The latter implements the protocol exposed by the Microsoft software TPM2 simulator.
    • The TCG TSS 2.0 Overview and Common Structures Specification forms the basis for all implementations in this project. NOTE: We deviate from this specification by increasing the value of TPM2_NUM_PCR_BANKS from 3 to 16 to ensure compatibility with TPM2 implementations that have enabled a larger than typical number of PCR banks. This larger value for TPM2_NUM_PCR_BANKS is expected to be included in a future revision of the specification.
    どのようなプログラミング言語を使ってプロジェクトを実装していますか？

  • 基本的なプロジェクト ウェブサイトのコンテンツ


    バッジには十分です！

    プロジェクトのウェブサイトは、ソフトウェアが何をするのか（何の問題を解決するのか）を簡潔に記述しなければなりません。 [description_good]

    https://github.com/tpm2-software/tpm2-tss/blob/master/README.md


    バッジには十分です！

    プロジェクトのウェブサイトは、取得方法、フィードバックの提供方法（バグ報告や拡張機能）、ソフトウェアへの貢献方法に関する情報を提供しなければなりません。 [interact]

    https://github.com/tpm2-software/tpm2-tss/blob/master/README.md and https://github.com/tpm2-software/tpm2-tss/blob/master/CONTRIBUTING.md


    バッジには十分です！

    貢献する方法に関する情報は、貢献プロセス（たとえばプル リクエストが使用されか、など）を説明する必要があります。 (URLが必要です) [contribution]

    Non-trivial contribution file in repository: https://github.com/tpm2-software/tpm2-tss/blob/master/CONTRIBUTING.md.


    バッジには十分です！

    貢献する方法に関する情報は、貢献を受け入れるための要件（たとえば、必要なコーディング標準への参照）を含むべきです。 (URLが必要です) [contribution_requirements]

    https://github.com/tpm2-software/tpm2-tss/blob/master/CONTRIBUTING.md


  • FLOSSライセンス

    プロジェクトのライセンスはどのようなものですか？


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアは、FLOSSとしてリリースされなければなりません。 [floss_license]

    The BSD-2-Clause license is approved by the Open Source Initiative (OSI).


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアに必要なライセンスは、オープンソース・イニシアチブ（OSI）によって承認されていることが推奨されています。 [floss_license_osi]

    The BSD-2-Clause license is approved by the Open Source Initiative (OSI).


    バッジには十分です！

    プロジェクトは、結果のライセンスをソースリポジトリの標準的な場所に投稿しなければなりません。 (URLが必要です) [license_location]

    Non-trivial license location file in repository: https://github.com/tpm2-software/tpm2-tss/blob/master/LICENSE.


  • ドキュメンテーション


    バッジには十分です！

    プロジェクトは、プロジェクトによって作成されたソフトウェアに関する基本的なドキュメンテーションを提供しなければなりません。 [documentation_basics]

    https://github.com/tpm2-software/tpm2-tss/blob/master/README.md - for General Overview https://github.com/tpm2-software/tpm2-tss/tree/master/doc - for General Documentation https://github.com/tpm2-software/tpm2-tss/tree/master/man - man pages for the some of the components Full Doxygen Documentation for ESAPI/FAPI layer - https://tpm2-tss.readthedocs.io/en/latest/


    バッジには十分です！

    プロジェクトは、プロジェクトによって作成されたソフトウェアの外部インタフェース（入力と出力の両方）を記述する参照ドキュメントを提供しなければなりません。 [documentation_interface]

    https://github.com/tpm2-software/tpm2-tss/tree/master/man - man pages for the some of the components

    Full Doxygen Documentation for ESAPI/FAPI layer - https://tpm2-tss.readthedocs.io/en/latest/


  • その他


    バッジには十分です！

    プロジェクトサイト（ウェブサイト、リポジトリ、およびダウンロードURL）は、TLSを使用したHTTPSをサポートしなければなりません。 [sites_https]

    Given only https: URLs - feature by Github


    バッジには十分です！

    プロジェクトは、議論（提案された変更や問題を含む）のための1つ以上の検索可能なメカニズムを持たなければならず、メッセージやトピックがURLでアドレス指定され、新しい人々がディスカッションのいくつかに参加できるようにしなければならず、クライアント側でプロプライエタリなソフトウェアのインストールを必要としないようにします。 [discussion]

    GitHub supports discussions on issues and pull requests. Also a searchable Mailing List https://lists.01.org/hyperkitty/list/tpm2@lists.01.org/


    バッジには十分です！

    プロジェクトは英語で文書を提供し、英語でコードに関するバグ報告とコメントを受け入れることができるべきです。 [english]

    All documentation and communication is done in English. https://github.com/tpm2-software/tpm2-tss/blob/master/README.md


    バッジには十分です！

    プロジェクトはメンテナンスされている必要があります。 [maintained]


（詳細）このバッジエントリを編集する権限を持つユーザーは？ 現在：[]



  • 公開されたバージョン管理ソースリポジトリ


    バッジには十分です！

    プロジェクトには、公開され、URLを持つ、バージョン管理のソース リポジトリがなければなりません。 [repo_public]

    Repository on GitHub, which provides public git repositories with URLs.


    バッジには十分です！

    プロジェクトのソース リポジトリは、どのような変更が行われたのか、誰が変更を行ったのか、いつ変更が行われたのかを追跡しなければなりません。 [repo_track]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.


    バッジには十分です！

    共同レビューを可能にするために、プロジェクトのソースリポジトリには、リリース間のレビューのための中間バージョンが含まれなければなりません。最終リリースのみを含めることはできません。 [repo_interim]

    The complete development is done on github - every interim version, every change, every commit can be found on the repository.


    バッジには十分です！

    プロジェクトのソース リポジトリに共通の分散バージョン管理ソフトウェア（gitなど）を使用することを推奨します。 [repo_distributed]

    Repository on GitHub, which uses git. git is distributed.


  • 一意的なバージョン番号


    バッジには十分です！

    プロジェクトの結果には、ユーザーが使用することを意図されたリリースごとに固有のバージョン識別子が必要です。 [version_unique]

    Semantic versioning scheme is used and the release process is documented in https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md


    バッジには十分です！

    リリースには、Semantic Versioning (SemVer)またはCalendar Versioning (CalVer)のバージョン番号形式を使用することが推奨されます。CalVerを使用する場合は、マイクロレベル値を含めることが推奨されます。 [version_semver]

    Semantic versioning scheme is used and the release process is documented in https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md


    バッジには十分です！

    プロジェクトがバージョン管理システム内の各リリースを特定することが推奨されています。たとえば、gitを使用しているユーザーがgitタグを使用して各リリースを特定することが推奨されています。 [version_tags]

    Every release is tagged with a signed tag. Even release candidates are marked with a signed tag. https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md


  • リリースノート


    バッジには十分です！

    プロジェクトは、各リリースにおいて、ユーザーがアップグレードすべきかどうか、また、アップグレードの影響を判断できるよう、そのリリースの主要な変更の要約を説明したリリースノートを提供しなければなりません（MUST）。リリースノートは、バージョン管理ログの生の出力であってはなりません（例えば、 "git log"コマンドの結果はリリースノートではない）。プロジェクトの成果物が複数の場所で再利用されることを意図していないプロジェクト（単独のウェブサイトやサービスのためのソフトウェアなど）で、かつ、継続的・断続的な配布を行う場合は、「該当なし」を選択することができます。 (URLが必要です) [release_notes]

    Non-trivial release notes file in repository: https://github.com/tpm2-software/tpm2-tss/blob/master/CHANGELOG.md. They are also included on the Release Page https://github.com/tpm2-software/tpm2-tss/releases


    バッジには十分です！

    リリースノートでは、このリリースで修正された、リリースの作成時にすでにCVE割り当てなどがあった、公に知られているランタイムの脆弱性をすべて特定する必要があります。 ユーザーが通常、ソフトウェアを実際に更新できない場合（たとえば、カーネルの更新によくあることです）、この基準は該当なし（N/A）としてマークされる場合があります。 この基準はプロジェクトの結果にのみ適用され、依存関係には適用されません。 リリースノートがない場合、または公に知られている脆弱性がない場合は、[N/A]を選択します。 [release_notes_vulns]

    Currently there are no known CVE entries - nevertheless, security relevant fixes are marked as such.


  • バグ報告プロセス


    バッジには十分です！

    プロジェクトは、ユーザーが不具合報告を送信するプロセスを提供しなければなりません（たとえば、課題トラッカーやメーリングリストを使用します）。 (URLが必要です) [report_process]

    https://github.com/tpm2-software/tpm2-tss/blob/master/CONTRIBUTING.md and standard Github Issue Tracker https://github.com/tpm2-software/tpm2-tss/issues Mailing list is also a possibility, as mentioned in the Readme.md - https://lists.01.org/hyperkitty/list/tpm2@lists.01.org/


    バッジには十分です！

    プロジェクトは、個々の課題を追跡するための課題トラッカーを使用するべきです。 [report_tracker]

    Yes - https://github.com/tpm2-software/tpm2-tss/issues


    バッジには十分です！

    このプロジェクトは、過去2〜12か月間に提出された多数のバグ報告の受領を認めなければなりません。応答に修正を含める必要はありません。 [report_responses]

    Yes - Issues: 27 open, 656 fixed/closed - https://github.com/tpm2-software/tpm2-tss/issues / Pull Requests: 1 open, 1239 closed - https://github.com/tpm2-software/tpm2-tss/pulls


    バッジには十分です！

    プロジェクトは、直近2〜12ヶ月（2ヶ月を含む）に増強要求の多数（> 50％）に対応すべきです。 [enhancement_responses]

    Yes - Issues: 27 open, 656 fixed/closed - https://github.com/tpm2-software/tpm2-tss/issues / Pull Requests: 1 open, 1239 closed - https://github.com/tpm2-software/tpm2-tss/pulls


    バッジには十分です！

    プロジェクトは、後で検索するために、レポートとレスポンスのアーカイブを公開する必要があります。 (URLが必要です) [report_archive]

    Yes - Issues: 27 open, 656 fixed/closed - https://github.com/tpm2-software/tpm2-tss/issues / Pull Requests: 1 open, 1239 closed - https://github.com/tpm2-software/tpm2-tss/pulls Public Mailing List Archive: https://lists.01.org/hyperkitty/list/tpm2@lists.01.org/


  • 脆弱性報告プロセス


    バッジには十分です！

    プロジェクトは、脆弱性を報告するプロセスをプロジェクト サイトに公開しなければなりません。 (URLが必要です) [vulnerability_report_process]

    https://github.com/tpm2-software/tpm2-tss/blob/master/CONTRIBUTING.md - although brief, it is stated how to report security bugs.


    バッジには十分です！

    プライベート脆弱性報告がサポートされている場合、プロジェクトは、プライベートに保持された方法で情報を送信する方法を含んでいなくてはなりません。 (URLが必要です) [vulnerability_report_private]

    Handled via Intel's Security Response Team https://www.intel.com/content/www/us/en/security-center/vulnerability-handling-guidelines.html as documented in https://github.com/tpm2-software/tpm2-tss/blob/master/CONTRIBUTING.md -


    バッジには十分です！

    過去6ヶ月間に受け取った脆弱性報告に対するプロジェクトの初期応答時間は、14日以下でなければなりません。 [vulnerability_report_response]

    Yes - handled via Intel's Security Response Team, fixed and coordinated


  • 作業ビルドシステム


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアを利用するためにビルドが必要な場合、プロジェクトは、ソース コードからソフトウェアを自動的にリビルドできる作業ビルド システムを提供しなければなりません。 [build]

    Each commit is automatically compiled using travis CI and AppVeyor. Each pull request is also automatically compiled travis CI and AppVeyor. https://travis-ci.org/tpm2-software/tpm2-tss and https://ci.appveyor.com/project/tpm2-software/tpm2-tss


    バッジには十分です！

    ソフトウエアをビルドするために、一般的なツールを使用することをお勧めします。 [build_common_tools]

    The build step of the software is based on the ubiquitous 'autotools' - known as "./configure && make && sudo make install" The software can also be built via a dockerfile.


    バッジには十分です！

    プロジェクトは、FLOSSツールだけを使用してビルドができるようにするべきです。 [build_floss_tools]

    It relies on autotools for building. Other software/libraries are also covered by floss licenses.


  • 自動テスト スイート


    バッジには十分です！

    プロジェクトは、FLOSSとして公開されている自動テストスイートを少なくとも1つ使用する必要があります（このテストスイートは、別個のFLOSSプロジェクトとして維持される場合があります）。 プロジェクトは、テストスイートの実行方法を明確に示すか文書化する必要があります（たとえば、継続的インテグレーション（CI）スクリプトを介して、またはBUILD.md、README.md、CONTRIBUTING.mdなどのファイルの文書を介して）。 [test]

    The tests are checked in under https://github.com/tpm2-software/tpm2-tss/tree/master/test and are perfomed on each commit using travis-ci. https://travis-ci.org/tpm2-software/tpm2-tss


    バッジには十分です！

    テスト スイートは、その言語の標準的な方法で呼び出すことができるべきです。 [test_invocation]

    invocation via simple standard 'make check'


    バッジには十分です！

    テスト スイートは、コードブランチ、入力フィールド、および機能のほとんど（または理想的にはすべて）をカバーすることが推奨されています。 [test_most]

    Code Coverage by automated testsuite (via travis-ci) is automatically reported to coveralls and is at about 85+% https://coveralls.io/github/tpm2-software/tpm2-tss?branch=master


    バッジには十分です！

    プロジェクトは、継続的インテグレーション（新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動テストが実行される）を実装することを推奨されています。 [test_continuous_integration]

    The tests are checked in under https://github.com/tpm2-software/tpm2-tss/tree/master/test and are perfomed on each commit using travis-ci. https://travis-ci.org/tpm2-software/tpm2-tss


  • 新機能テスト


    バッジには十分です！

    プロジェクトは、プロジェクトで作成されたソフトウェアに主要な新機能が追加されたときに、その機能のテストを自動化されたテスト スイートに追加する必要があるという一般的な方針（正式でも、正式でなくても構いません）を持っていなければなりません。 [test_policy]

    https://github.com/tpm2-software/tpm2-tss/blob/master/CONTRIBUTING.md This is also part of the review cycle and has been enforced multple times. But could be made clearer - TODO


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアの最新の大きな変更で、テストを追加するための test_policy が守られているという証拠がプロジェクトに存在しなければなりません。 [tests_are_added]

    General Code Coverage is always improved and must be kept above 80%. New tests are also mentioned in the release notes.


    バッジには十分です！

    テストを追加するこのポリシー（test_policyを参照）を変更提案に関する手順で文書化することを推奨します。 [tests_documented_added]

    Part of the review cycle - but could be made clearer - TODO.


  • 警告フラグ


    バッジには十分です！

    プロジェクトは、選択した言語でこの基準を実装することができる少なくとも1つのFLOSSツールがあれば、1つまたは複数のコンパイラ警告フラグ、「安全」言語モードを使用可能にするか、分離 「リンター」ツールを使用してコード品質エラーまたは共通の単純なミスを検索しなければなりません。 [warnings]

    A lot of the most common secure compile flags are enabled in configure per default. https://github.com/tpm2-software/tpm2-tss/blob/master/configure.ac#L192

    Also the code is compiled using gcc and clang to enable more warning coverage. In addition to that static code analysis is done via coverity and scan-build (via clang).


    バッジには十分です！

    プロジェクトは警告を出さなければならない。 [warnings_fixed]

    All compiler warnings are treated as errors ("-Werror"). https://github.com/tpm2-software/tpm2-tss/blob/master/configure.ac#L196

    Static Code Analyzer Warnings are adressed / reviewed on a regular basis https://scan.coverity.com/projects/tpm2-tss


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアにある警告に、実際的な場合には、最大限に厳格になることを推奨されています。 [warnings_strict]

    A lot of the most common secure compile flags are enabled in configure per default. https://github.com/tpm2-software/tpm2-tss/blob/master/configure.ac#L192

    Also the code is compiled using gcc and clang to enable more warning coverage. In addition to that static code analysis is done via coverity and scan-build (via clang).


  • セキュリティに関する開発知識


    バッジには十分です！

    プロジェクトには、安全なソフトウェアを設計する方法を知っている少なくとも1人の主要な開発者が必要です。 （正確な要件については、「詳細」を参照してください。） [know_secure_design]

    The design of the specification of the software is performed within a Working Group within the Trusted Computing Group. Software development in the context of the TCG is always related to security and secure software. The maintainers have several years of experience in developing secure software.


    バッジには十分です！

    プロジェクトの主要開発者の少なくとも1人は、この種のソフトウェアの脆弱性につながる一般的な種類のエラーを知っていなければならず、それぞれを対策または緩和する少なくとも1つの方法を知っていなければなりません。 [know_common_errors]

    The design of the specification of the software is performed within a Working Group within the Trusted Computing Group. Software development in the context of the TCG is always related to security and secure software. The maintainers have several years of experience in developing secure software.


  • 優良な暗号手法を使用する

    一部のソフトウェアは暗号化メカニズムを使用する必要がないことに注意してください。あなたのプロジェクトが作成するソフトウェアが、(1) 暗号化機能を含む、アクティブ化する、または有効化し、(2) 米国（US）から米国外または米国市民以外にリリースされる可能性がある場合は、法的に義務付けられた追加手順の実行を要求される可能性があります。通常、これにはメールの送信が含まれます。詳細については、 Understanding Open Source Technology & US Export Controls（「オープンソース技術と米国の輸出管理について」）の暗号化のセクションを参照してください。

    バッジには十分です！

    プロジェクトによって作成されたソフトウェアは、デフォルトで、一般に公開され、専門家によってレビューされている暗号プロトコルとアルゴリズムを使用しなければなりません。（暗号プロトコルとアルゴリズムが使用される場合） [crypto_published]

    The design of the specification of the software is performed within a Working Group within the Trusted Computing Group. Software development in the context of the TCG is always related to security and secure software. The cryptography depends on public cryptographic protocols and algorithms like TLS, sha, aes, rsa....


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアがアプリケーションまたはライブラリであり、主な目的が暗号の実装でない場合、暗号機能を実装するために特別に設計されたソフトウェアを呼び出すだけにするべきです。自分用に（暗号機能を）再実装するべきではありません。 [crypto_call]

    It uses openssl or mbedtls as crypto-backends. It does not implement its own crypto.


    バッジには十分です！

    暗号に依存するプロジェクトによって作成されるソフトウェアのすべての機能は、FLOSSを使用して実装可能でなければなりません。 [crypto_floss]

    It uses openssl or mbedtls as crypto-backends - both are FLOSS.


    バッジには十分です！

    プロジェクトによって作成されたソフトウェア内にあるセキュリティ メカニズムは、少なくとも、2030年までのNIST最小要件（2012年）を満たすデフォルト鍵長を使用しなければなりません。より小さな鍵長を完全に無効になるおうに、ソフトウェアを構成できなければなりません。 [crypto_keylength]

    The TPM specification currently still allows the usage of these algorithms/keysizes even if better algorithms are available, so we must support them.

    However a new configure flag --disable-weakcrypto was introduced which prevents the usage of these algorithms as much as possible.


    バッジには十分です！

    プロジェクトによって生成されたソフトウェア内のデフォルトのセキュリティメカニズムは、壊れた暗号化アルゴリズム（MD4、MD5、シングルDES、RC4、Dual_EC_DRBGなど）に依存したり、実装する必要がない限り、コンテキストに不適切な暗号化モードを使用したりしてはなりません。相互運用可能なプロトコル（実装されたプロトコルがネットワークエコシステムによって広くサポートされている標準の最新バージョンであり、そのエコシステムではそのようなアルゴリズムまたはモードの使用が必要であり、そのエコシステムはこれ以上安全な代替手段を提供しません）。これらの壊れたアルゴリズムまたはモードが相互運用可能なプロトコルに必要な場合、ドキュメントには、関連するセキュリティリスクと既知の緩和策を記載する必要があります。 [crypto_working]

    tpm2-tss does not support any of these. Only SM3 may be an issue in the future here. Re-assessment will be done regularly - TODO.


    バッジには十分です！

    プロジェクトによって作成されたソフトウェア内のデフォルトのセキュリティ メカニズムは、既知の重大な脆弱性を持つ暗号アルゴリズムやモード（たとえば、SHA-1暗号ハッシュ アルゴリズムまたはSSHのCBC モード）に依存するべきではありません。 [crypto_weaknesses]

    The TPM specification currently still allows the usage of these algorithms, even if better algorithms are available, so we must support them.

    However a new configure flag --disable-weakcrypto was introduced which prevents the usage of these algorithms as much as possible.


    バッジには十分です！

    プロジェクトによって作成されたソフトウェア内のセキュリティ メカニズムは、鍵合意プロトコルのための完全な順方向秘密を実装するべきなので、もし長期鍵が将来侵害された場合でも、長期鍵のセットから導出されるセッション鍵は侵害されません。 [crypto_pfs]

    tpm2-tss does not establish cryptographic sessions that qualify for perfect forward secrecy. The Auth-Sessions to the TPM would be prone to this issue, but those are bound to the hardware specification and the private keys are held inside SmartCards-like ICs aka TPMs. Nothing we can do here.


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアが外部ユーザーの認証用のパスワードの保存を引き起こす場合、パスワードは、キーストレッチ（反復）アルゴリズム（Argon2id、Bcrypt、Scrypt、PBKDF2など）を使用して、ユーザーごとのソルトで反復ハッシュとして保存される必要があります。OWASP Password Storage Cheat Sheetも参照してください）。 [crypto_password_storage]

    tpm2-tss does not store passwords.


    バッジには十分です！

    プロジェクトによって作成されたソフトウェア内のセキュリティ メカニズムは、暗号学的にセキュアな乱数発生器を使用して、すべての暗号鍵とナンスを生成しなければなりません。暗号学的にセキュアでない発生器を使用してはいけません。 [crypto_random]

    We use gcry_randomize with GCRY_STRONG_RANDOM (https://github.com/tpm2-software/tpm2-tss/blob/master/src/tss2-esys/esys_crypto_gcrypt.c#L496) or OpenSSL's RAND_bytes (https://github.com/tpm2-software/tpm2-tss/blob/master/src/tss2-esys/esys_crypto_ossl.c#L532) for randomness.


  • MITM（man-in-the-middle：中間者）攻撃に対応できる安全な配信


    バッジには十分です！

    プロジェクトは、MITM攻撃に対抗する配信メカニズムを使用しなければならない。httpsまたはssh+scpを使用することは許容されます。 [delivery_mitm]

    Each release is performed with signed tags as described in https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md Apart from that the software can also be downloaded via https or via the git protocol.


    バッジには十分です！

    暗号ハッシュ（たとえばSHA1SUM）は、http経由で運んではならず、暗号署名をチェックすることなしに使用してはいけません。 [delivery_unsigned]

    Each release is performed with signed tags as described in https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md The signature verification is performed by github on the release page and the signature of the release packages can be retrieved via https.


  • 広く知られた脆弱性を修正


    バッジには十分です！

    60日を超えて公的に知られている中程度または重大度のパッチが適用されていない脆弱性は存在してはなりません。 [vulnerabilities_fixed_60_days]

    No publicly known vulnerabilities open.


    バッジには十分です！

    プロジェクトは、すべての重要な脆弱性を、報告された後迅速に修正するべきです。 [vulnerabilities_critical_fixed]

    No publicly known vulnerabilities open.


  • その他のセキュリティ上の課題


    バッジには十分です！

    公開リポジトリは、パブリックアクセスを制限するための有効なプライベートクレデンシャル（たとえば、有効なパスワードやプライベートキー）を漏らしてはなりません。 [no_leaked_credentials]

    No leaks.


  • 静的コード解析


    バッジには十分です！

    選択した言語でこの基準を実装するFLOSSツールが少なくとも1つある場合、少なくとも1つの静的コード分析ツール（コンパイラの警告と「安全な」言語モード以外）を、ソフトウェアの主要な製品リリースの提案に、リリース前に適用する必要があります。 [static_analysis]

    Coverity Scan and scan-build from clang/llvm.


    バッジには十分です！

    static_analysis基準に使用される静的解析ツールの少なくとも1つが、分析された言語または環境における共通の脆弱性を探すためのルールまたはアプローチを含むことが、推奨されています。 [static_analysis_common_vulnerabilities]

    Covered by coverity.


    バッジには十分です！

    静的コード解析で発見された中程度および重大度の悪用可能な脆弱性はすべて、それらが確認された後、適時に修正されなくてはなりません。 [static_analysis_fixed]

    https://scan.coverity.com/projects/tpm2-tss They are fixed/evaluated before a release - https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md


    かろうじてバッジには十分です。

    静的ソースコード解析は、コミットごと、または少なくとも毎日実行することをお勧めします。 [static_analysis_often]

    Coverity is run before a release - https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md Scan-build is run on a per commit basis.


  • 動的コード分析


    かろうじてバッジには十分です。

    リリース前に、ソフトウェアの主要な製品リリースに少なくとも1つの動的解析ツールを適用することが示唆されています。 [dynamic_analysis]

    Currently not implemented - code coverage is above 80% using the automatic testsuite.


    かろうじてバッジには十分です。

    プロジェクトで作成されたソフトウェアにメモリ安全でない言語（CやC ++など）を使用して作成されたソフトウェアが含まれている場合、少なくとも1つの動的ツール（たとえば、ファジーまたはウェブ アプリケーション スキャナ）を、バッファの上書きなどのメモリの安全性の問題を検出するメカニズムと一緒にいつも使用します。プロジェクトがメモリ安全でない言語で書かれたソフトウェアを作成しない場合は、「該当なし」（N/A）を選択します。 [dynamic_analysis_unsafe]

    Currently not implemented - code coverage is above 80% using the automatic testsuite including some boundary checks.

    Valgrind can be easily used with make check-valgrind


    かろうじてバッジには十分です。

    プロジェクトでは、多くのアサーションを可能にする少なくとも一部の動的分析（テストやファジングなど）の構成を使用することをお勧めします。多くの場合、これらのアサーションは本番ビルドでは有効にしないでください。 [dynamic_analysis_enable_assertions]

    Currently not implemented - code coverage is above 80% using the automatic testsuite


    バッジには十分です！

    動的コード分析で発見されたすべての中程度および重大度の悪用可能な脆弱性は、確認された後、適時に修正されなければなりません。 [dynamic_analysis_fixed]

    Currently not implemented



このデータは、Creative Commons Attribution version 3.0以降のライセンス（CC-BY-3.0 +）のもとで利用できます。すべての人がデータを自由に共有および適応できますが、適切にクレジットを入れる必要があります。 Peter HueweとOpenSSFベストプラクティス バッジ貢献者のクレジットを入れてください。

プロジェクト バッジ登録の所有者： Peter Huewe.
エントリの作成日時 2018-11-08 16:22:22 UTC、 最終更新日 2020-11-24 13:31:51 UTC 最後に2019-04-01 19:29:20 UTCにバッジ合格を達成しました。

もどる