계: Security Features

소프트웨어 보안은 보안 소프트웨어가 아닙니다. 여기서는 인증, 액세스 제어, 기밀성, 암호화, 권한 관리 등의 항목에 대해 설명합니다.

Weak Encryption: Insufficient Key Size

Abstract

불충분한 키 크기를 사용하면 강력한 암호화 알고리즘이더라도 무차별 대입 공격에 크게 취약해질 수 있습니다.

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

불충분한 키 크기를 사용하면 강력한 암호화 알고리즘이더라도 무차별 대입 공격에 크게 취약해질 수 있습니다.

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;
  }