계: Security Features

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

Weak Cryptographic Signature: User-Controlled Key Size

Abstract

키 크기 매개 변수를 사용하는 암호화 서명 함수에 감염된 키 크기 값을 전달해서는 안 됩니다.

Explanation

사용자가 제어하는 값을 통해 키 크기를 결정할 수 있도록 허용하면 공격자가 빈 키를 지정하여 암호화된 데이터의 무결성을 유지하는 암호화 서명을 수정하게 될 수도 있습니다. 0이 아닌 값을 지정해야 하더라도 공격자는 여전히 키 크키 값을 최대한 낮게 지정하여 암호화된 데이터의 무결성을 떨어뜨릴 수 있습니다.

약한 암호화 해시: 사용자 제어 키 크기 문제는 다음과 같은 경우에 발생합니다.

1. 신뢰할 수 없는 소스를 통해 데이터가 프로그램에 입력됩니다.

2. 암호화 서명 함수 내에서 키 크기 매개 변수의 전체 또는 일부로 사용자가 제어하는 데이터가 사용됩니다.

여러 소프트웨어 보안 취약점과 마찬가지로 약한 암호화 해시: 사용자 제어 키 크기는 목적의 수단일 뿐 목적 자체는 아닙니다. 이 취약점은 본질적으로 간단 명료합니다. 즉, 공격자가 응용 프로그램에 악성 데이터를 전달하며 이 데이터가 암호화를 수행하는 동안 키 크기 값의 전체 또는 일부로 사용됩니다.

현재 암호 작성법 지침에 따르면 RSA 및 DSA 알고리즘과 함께 적어도 2048비트의 키 길이를 사용해야 합니다. 하지만 계산 기능과 인수 분해 기술[1]이 지속적으로 발전하기 때문에 나중에는 권장되는 키 크기가 분명 더 커질 것입니다. 사용자 입력이 키 크기 값에 부분적으로만 사용되더라도 서명의 보안을 크게 약화시킬 수 있으므로 암호화된 데이터의 무결성도 대폭 떨어뜨릴 수 있습니다.

예제 1: 다음 코드에서는 사용자 제어 키 크기 매개 변수를 사용하여 DSA 서명 키를 생성합니다.


...
DSA dsa1 = new DSACryptoServiceProvider(Convert.ToInt32(TextBox1.Text));
...

사용자가 key_len을 확인할 수 있어야 하는 사용 사례는 거의 없으며, 설령 있다고 하더라도 해당 값이 숫자 값이며 적절한 키 크기 값 범위 내에 있는지 모두 확인하도록 적절한 보호 조치를 취해야 합니다. 대부분의 경우 이는 충분히 높은 하드코드된 숫자여야 합니다.

References

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

[2] Elaine Barker and Allen Roginsky NIST Special Publication 800-131A: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths. 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-001188, 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), SC-23 Session Authenticity (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, SC-23 Session Authenticity

[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), 6.2.7 Algorithms (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.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-002020 CAT II

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

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

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

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

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

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

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

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

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

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

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

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

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

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

desc.dataflow.dotnet.weak_cryptographic_signature_user_controlled_key_size

Abstract

키 크기를 사용하는 암호화 서명 함수는 감염된 키 크기 값을 수신할 수 있습니다.

Explanation

사용자가 제어하는 값을 통해 키 크기를 결정할 수 있도록 허용하면 공격자가 빈 키를 지정하여 암호화된 데이터의 무결성을 유지하는 암호화 서명을 수정하게 될 수도 있습니다. 0이 아닌 값을 지정해야 하더라도 공격자는 여전히 키 크키 값을 최대한 낮게 지정하여 암호화된 데이터의 무결성을 떨어뜨릴 수 있습니다.

약한 암호화 서명: 사용자 제어 키 크기 이슈는 다음과 같은 경우에 발생합니다.

1. 신뢰할 수 없는 소스를 통해 데이터가 프로그램에 입력됩니다.

2. 암호화 서명 함수 내에서 키 크기 매개 변수의 전체 또는 일부로 사용자가 제어하는 데이터가 사용됩니다.

여러 소프트웨어 보안 취약점과 마찬가지로 약한 암호화 서명: 사용자 제어 키 크기는 목적 달성을 위한 수단이며 그 자체가 목적은 아닙니다. 이 취약점은 본질적으로 간단 명료합니다. 즉, 공격자가 응용 프로그램에 악성 데이터를 전달하며 이 데이터가 키 크기 값의 전체 또는 일부로 사용되어 암호화가 수행됩니다.

현재 암호 작성법 지침에 따르면 RSA 및 DSA 알고리즘과 함께 적어도 2048비트의 키 길이를 사용해야 합니다. 하지만 계산 기능과 인수 분해 기술[1]이 지속적으로 발전하기 때문에 나중에는 권장되는 키 크기가 분명 더 커질 것입니다. 사용자 입력이 키 크기 값에 부분적으로만 사용되더라도 서명의 보안을 약화시킬 수 있으므로 암호화된 데이터의 무결성도 떨어뜨릴 수 있습니다.

예제 1: 다음 코드에서는 사용자가 제어하는 키 크기 매개 변수를 사용하여 DSA 서명 키를 생성합니다.


...
dsa.GenerateParameters(params, rand.Reader, key_len)
privatekey := new(dsa.PrivateKey)
privatekey.PublicKey.Parameters = *params
dsa.GenerateKey(privatekey, rand.Reader)
...

사용자가 key_len을 지정해야 하는 경우는 거의 없습니다. 키 길이를 지정해야 하는 경우에는 해당 값이 숫자 값이며 적절한 키 크기 값 범위 내에 있는지 모두 확인해야 합니다. 대부분의 경우에는 충분히 큰 하드코드된 키 크기를 선택합니다.