Software Product Confirmation Testing: Security Verification of System Encryption Algorithms (AES/RSA)
Software product confirmation testing for system encryption algorithms (AES/RSA) begins with checking the compliance of algorithm versions and configurations. The AES algorithm should use a key length of AES-128 or higher, while the RSA algorithm should have a key length of at least 2048 bits, which is the industry standard for security. We tested a financial software where AES used AES-128, but the configuration set the key rotation period to “permanent”, which does not meet the requirement for “periodic rotation”. This configuration vulnerability increases the risk of key leakage, and it needs to be recorded and adjusted for the rotation period.
1. Verification of Encryption Algorithm Deployment
Check whether the system enables the corresponding algorithms in specified scenarios, such as using AES encryption for sensitive data storage and RSA asymmetric encryption for data transmission.
2. Security of Key Generation and Management
AES key generation must be random and should not use fixed keys or simple sequences; RSA key pair generation must ensure that the private key is not leaked and is stored in a secure medium. We tested an e-commerce software where the AES key used a simple sequence like “12345678”, which could be easily cracked, and the private key was stored in a regular database without encryption protection. This key management vulnerability could lead to the failure of the entire encryption system, necessitating a redesign of the key generation and storage scheme.
3. Integrity Verification of Encrypted Data
After encrypting user phone numbers and ID numbers with AES, the decrypted data must match the original data without any garbled characters or data loss. We tested a government software where the AES encryption of ID numbers resulted in errors in the last two digits upon decryption, which was found to be caused by data truncation during encryption. This integrity issue in encryption could affect business operations and must be fixed in the encryption logic.
4. Validity of RSA Algorithm Signature and Verification
After signing data with the RSA private key, verify it with the public key to see if it passes normally; if the signed data is tampered with, the verification should indicate “invalid signature”. We encountered a payment software where tampered signed data still passed verification, which was found to be due to a missing verification logic that only checked for the existence of the signature without verifying its integrity. This RSA security vulnerability could allow data tampering to go undetected, requiring urgent repair.
5.Verification of Encryption Algorithm’s Resistance to Attacks
Simulate a brute-force attack to attempt to crack the AES key and see if it can be successfully done in a short time; for the RSA algorithm, try to mathematically factor the key to verify its security. We tested an enterprise software where the AES key length was AES-128, and the brute-force tool ran for 72 hours without cracking it, meeting security requirements; however, if AES-64 were used, it could be cracked in a few hours. This insufficient resistance to attacks necessitates an upgrade of the key length.
6. Performance Compatibility of Encryption Algorithms
In high-concurrency scenarios, after enabling AES/RSA encryption, the system response time should not significantly increase; for example, if the response time without encryption is 0.5 seconds, it should not exceed 1 second after encryption. We tested a social software where enabling RSA encryption increased the response time from 0.6 seconds to 3 seconds, degrading user experience. It was found that the encryption algorithm was not optimized, necessitating adjustments to the encryption process, such as implementing incremental encryption for high-frequency data transmissions to balance security and performance.
7. Encryption Security in Abnormal Scenarios
During power outages or network interruptions, data being encrypted must not leave plaintext remnants, and the encryption state must be able to resume normally after a restart. We tested an office software where files being encrypted left partial plaintext during a power outage, and the encryption process was interrupted upon restart. This security vulnerability in abnormal scenarios could lead to data leakage, necessitating optimization of the encryption interruption handling mechanism.
Record verification results and rectification suggestions: Algorithms with configurations that fully meet security requirements are marked as “passed verification”; those with vulnerabilities should have detailed descriptions of the problem types, such as insufficient key length or deployment deficiencies, along with specific rectification plans, such as upgrading AES to 256 bits or fixing the RSA verification logic. Ensure that the software product confirmation testing: security verification of system encryption algorithms (AES/RSA) results are clear and can directly guide development optimization to enhance system encryption security.
Scan the QR code to follow us
