界: Security Features

ソフトウェアのセキュリティは、セキュリティソフトウェアではありません。ここでは、認証、アクセス制御、機密性、暗号化、権限管理などのトピックについて説明します。

Weak Encryption: Insufficient Key Size

Abstract

強力な暗号化アルゴリズムでも、鍵のサイズが不十分だと、Brute-Force 攻撃に対して脆弱となる可能性があります。

Explanation

現在の暗号化ガイドラインでは、RSA アルゴリズムでは最小でも 2048 ビットの鍵の長さを使用する必要があるとされています。しかし、演算処理能力とファクタリング技術が進歩し続ける限り [1]、将来的に推奨される鍵のサイズが増大するのは避けられません。

例 1: 次のコードは、512 ビットの暗号鍵の RSA アルゴリズムを使用しています。


  static public byte[] EncryptWithRSA(byte[] plaintext, RSAParameters key) {
    try {
      RSACryptoServiceProvider rsa = new RSACryptoServiceProvider(512);
      rsa.ImportParameters(key);
      return rsa.Encrypt(plaintext, true);
    }
    catch(CryptographicException e) {
      Console.WriteLine(e.Message);
      return null;
    }
  }

対称鍵暗号の場合、鍵の長さは最低でも 128 ビットである必要があります。

References

[1] J. Cheng 307-digit key crack endangers 1024-bit RSA

[2] Cryptographic Algorithms and Key Sizes for Personal Identity Verification NIST

[3] B. Chess and J. West, Secure Programming with Static Analysis. Boston, MA: Addison-Wesley, 2007.

[4] Standards Mapping - Common Weakness Enumeration CWE ID 326

[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450

[6] Standards Mapping - FIPS200 MP

[7] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection

[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)

[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection

[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.8.3 Single or Multi Factor One Time Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.3 Algorithms (L2 L3), 6.2.4 Algorithms (L2 L3), 6.2.5 Algorithms (L2 L3), 6.2.6 Algorithms (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)

[11] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography

[12] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography

[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1

[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage

[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage

[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage

[17] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure

[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure

[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures

[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.6.1, Requirement 6.5.8

[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.6.1, Requirement 6.3.1.3, Requirement 6.5.8

[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.6.1, Requirement 6.5.3

[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.6.1, Requirement 6.5.3

[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.6.1, Requirement 6.5.3

[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.6.1, Requirement 6.5.3

[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.6.1, Requirement 6.5.3

[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.6.1, Requirement 6.2.4

[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 3.6.1, Requirement 6.2.4

[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography

[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design

[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design

[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II

[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II

[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II

[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II

[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II

[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II

[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II

[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II

[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II

[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II

[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II

[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II

[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II

[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II

[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II

[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II

[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II

[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II

[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II

[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II

[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II

[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II

desc.semantic.dotnet.weak_encryption_insufficient_key_size

Abstract

強力な暗号化アルゴリズムでも、鍵のサイズが不十分だと、Brute-Force 攻撃に対して脆弱となる可能性があります。

Explanation

現在の暗号化ガイドラインでは、RSA アルゴリズムでは最小でも 2048 ビットの鍵の長さを使用する必要があるとされています。しかし、演算処理能力とファクタリング技術が進歩し続ける限り [1]、将来的に推奨される鍵のサイズが増大するのは避けられません。

例 1: 次のコードは、512 ビットの RSA 暗号鍵を生成しています。


  EVP_PKEY * get_RSA_key() {
    unsigned long err;
    EVP_PKEY * pkey;
    RSA * rsa;
    rsa = RSA_generate_key(512, 35, NULL, NULL);
    if (rsa == NULL) {
      err = ERR_get_error();
      printf("Error = %s\n",ERR_reason_error_string(err));
      return NULL;
    }
    pkey = EVP_PKEY_new();
    EVP_PKEY_assign_RSA(pkey, rsa);
    return pkey;
  }