All operating systems need entropy to generate random bits to create keys for cryptographic algorithms. Randomness...
is critical to secure those algorithms and make guessing or predicting the cryptographic keys that much harder for attackers.
While there are algorithms capable of generating pseudo-random bits that can produce random-seeming keys, an attacker who is aware that a pseudo-random algorithm is being used to generate keying material can defeat even the strongest cryptography by guessing the keys being used.
Operating systems generate entropy using a variety of different sources, though entropy sources that work well for one operating system may not work for another operating system. The National Institute of Standards and Technology has published guidance for testing and validating vendor-neutral entropy sources for most operating systems.
Entropy sources need noise, which should originate from a source that generates data that is inherently unpredictable. The entropy source may be a physical noise source, which requires dedicated hardware to generate randomness, or it may be a non-physical noise source, which is usually generated using the output from system processes or by prompting the user for input, such as random mouse movements.
Entropy sources must be validated with a health test to verify that they are working as required. If the tests show that the entropy sources are not generating random data, attackers may easily guess cryptographic keys.
Entropy sources that have been properly tested may not necessarily be sufficient to secure software applications containing validated cryptographic algorithms. To mitigate application failures, the software development lifecycle (SDLC) can be used to secure the application in each lifecycle phase -- from requirements analysis to deployment and beyond. Furthermore, security experts with backgrounds in entropy source validation can help spot security issues that the project manager may have missed.
To better secure applications, developers should consider entropy sources from every phase of the SDLC, from requirements analysis for new applications through maintenance of mature applications.
Requirement analysis phase
It's far cheaper to catch problems in the required analysis phase than to fix security issues later in the SDLC. Software project managers should meet with security experts first, and then with potential users and other stakeholders to determine who will use the application, how the users will use it, what data the application will process, how the operating system will achieve entropy and what security issues the users may encounter.
The rate of entropy of a noise source should also be considered, as the higher the rate, the better chance the cryptographic algorithm will be effective.
The software design is prepared using the requirement specifications. A designer specifies how the new application should work, what constraints should be imposed on the application and how it should meet compliance requirements.
Security experts can help prevent or mitigate design failures by ensuring that the hardware and system are free of vulnerabilities and are not entropy-starved. Security experts should also help the designers set up access controls and work with quality experts to test the application and entropy sources.
Developers should be adequately trained on proper secure code implementation. A developer manual should be reviewed periodically by DevOps security experts on pseudo-randomness issues, minimum security controls, the handling of memory leakage in C programs and the discovery of flaws in the authentication protocols used to access the applications.
Issues that security experts discover should be found in the design phase before the development phase begins.
By this phase, entropy sources should have been validated to generate sufficiently strong cryptographic keys. To ensure that the application will not fail due to factors other than validated entropy services, code must be tested against security and other requirements. Security aspects of functional testing, such as unit testing, integration testing, system testing, acceptance testing and nonfunctional testing should also be considered.
The turnaround time for test results should be reasonably short, and you must determine how to handle application errors for debugging purposes. The logs should be formatted to enable developers, testers and security experts to collaboratively determine the source of application issues.
The deployment phase is divided into two parts. In the first part, the application is turned over to the security experts and customers.
The security experts conduct beta testing to ensure the application is secure and free of vulnerabilities, that the cryptographic keys generated by the entropy sources work properly, and that customers have proper access credentials. The customers also do beta testing to make sure the application works and that user, application and system requirements are met.
If any changes are needed or if any security or entropy issues are discovered, then security experts and customers report them to the project manager together. Once the application has been changed and any issues have been fixed, the second and final phase of deployment begins.
Once fully deployed, the final SDLC phase begins as customers use the developed application and security experts monitor the application and ensure that there are no new vulnerabilities. The security expert will revert the application to one of the previous lifecycle phases to fix the problem if:
- the rules for validating entropy sources have changed;
- the cryptographic algorithm is to be replaced with a more efficient version;
- the operating system running the application has become entropy-starved; or
- new application security issues are discovered.
As technology evolves, new entropy sources are being tested and validated. SDLC ensures that applications containing cryptographic algorithms and generated by validated entropy sources are secure so that the application will not fail after deployment.