Software Certification and Attestation Rajat Moona Director General

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

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

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.

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.

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 Du. V.

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

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

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.

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

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 MD 5, SHA 1, SHA 2 etc. )

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 MD 2, MD 4, MD 5, 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.

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 Du. V 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.

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.

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.

Detection of malicious code • By Challenge response mechanism

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

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

Detection of malicious code • While challenge response mechanism solves some issues – It still does not solve the problem if the Du. V 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

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

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.

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.

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.

Thank You