Software Certification and Attestation

1. Software Certification and Attestation Rajat Moona Director General, C-DAC

2. Issues • General purpose systems vs. embedded systems • Systems with embedded storage • Processors with embedded memories without any physical access • Inability to probe memory/storage contents • Increased dependency on the secure solutions

3. Software Certification • Isn’t about the software correctness. • Isn’t about the software verification or evaluation of programming skills • Is about ensuring that the software performs the stated goal to the best achievable manner. • Does not carry any malicious code • Often independent code examination results in better quality • but that can at best be the side effect of software certification and not its goal.

4. Software Attestation Problem • Given a certified software (aka reference software), • The problem is to identify if the system implementing the functionality is running the “same” software or not. • Assuming that the certified software image is available (byte-by-byte) • The solution is to compare each byte of the code in the system memory image. • But the system memory image is not accessible.

5. Associated challenges • Who will attest the software? • The issue largely is “who will have the reference software image?” • Even if the reference image is in a verification system from where it can not be read, • The verification system needs to read the memory contents from DuV.

6. Software Attestation Reference Software Software Attestation System Outcome: Verified? [Y/N] Device under verification (DuV)

7. Solution 1 Reference Software Software Attestation System Outcome: Verified? [Y/N] Device under verification (DuV) Interrogate and examine SAS sends a message to dump the memory contents and matches against the reference software.

8. Simple solution • The SAS sends a simple message. The return message is the whole image of the memory • Issue of the code protection • Volume of data and time to process. • A malicious system can still get round it by maintaining two copies – one to execute, another one for proving genuine-ness. • Alternate mechanisms: Challenge Response methods.

9. Malicious Device Reference Software DuV Software Attestation System Outcome: Verified? [Y/N]

10. Some problems are handlable • For example, the image of the software need not be given. Instead a hash can be computed and given. • Hashes are one way functions. (For example MD5, SHA1, SHA2 etc.)

11. One way functions • Problem: • Given a message m, find a number n derived from m in such a way that it is impractical to find m when only n is known. •  One way function. m can be converted to n but not vice versa. • A good hash function also has a property that given a message and its hash, it is impractical to find another message that results in the same hash. • Also known as Hash or Message Digest. • Various standard algorithms exist such as MD2, MD4, MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 etc. • One way functions are very commonly used. For example the passwords are stored in Unix systems using one-way functions. • Cryptographic applications and communications use one-way functions for applications such as digital signatures, message integrity etc.

12. Volume of processing • Can be handled by successive interrogating. • Memory may be viewed as an array of bytes. • Each interrogation message will provide an address (a) and length (l) the array to examine • The DuV will provide mem[a], mem[a+1] … mem[a+l-1] • Or the hash computed from these values. • Successive unplanned and random interrogations can remove the chances of the existence of the malicious code.

13. Malicious code • What are the possibilities? • Malicious code has to behave like genuine code in most cases, otherwise it will be noticed. • Malicious code can be activated through special inputs • By messages, by pressing a sequence of buttons, by remote control etc. • But the inputs mechanisms can not be increased. • Malicious code has to hide within the genuine code.

14. Malicious code • Can be an additional code • In which case, there must be some kinds of “jump” from the genuine code too. • Can be modified code. • Too much of modifications can be caught if the memory image is taken (and the scheme is likely to work). • Code can not be injected from outside unless the genuine code permits that and in that case, it is part of the functionality.

15. Detection of malicious code • By Challenge response mechanism

16. Challenge Response Authentication • Do you know that secret that I have? • Send a challenge • Expect a response which can be verified. • If verification is successful then with a very high probability, the other party is genuine. • Challenge • Must be fresh, or with at least non-guessable response, for each time. • Examples: • Time Stamp • Counter • Random Number

17. Authentication • Assume Secret existence at two sides Send rA Send E(KAB, rA) Send rB Send E(KAB, rB) B A What if I don’t have access to a cryptographic algorithm? KAB KAB

18. Detection of malicious code • While challenge response mechanism solves some issues • It still does not solve the problem if the DuV maintains separate copies of the code to execute and code for providing response. • Include the dynamic behaviors in the response verification. • Contents of RAM etc. • The RAM contents are time variant and not all are reproducible. • Select a set that is reproducible. But it limits the choices

19. Run-time • Examples of verifiable variables • Last message received from the outside • Last key pressed • Time of the day to certain precision • Correlation of all • Hash of all the keys pressed or all the messages received • Hash of time stamped messages/keys

20. Issues • What if the malicious device maintains these variables in the same manner also? • The problem is open but limits the options on the malicious code • Since the malicious code activation requires the same inputs and the code verification process does not know what input may be given.

21. Behavioral verification • Include the time taken to provide response to the challenge. • Since the malicious code will have to execute additional instructions, it will be slower to catch up. • The focus shifts to “what if the malicious device uses a faster processor?” • Relatively an easier mechanism to handle.

22. Conclusion • Software attestation problem is an interesting problem • Requires simple but enormous heuristic approaches • Solutions are imperfect but then • “Every criminal leaves a trail behind”. The issue is to recognize the trail.

23. Thank You