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 DuV.

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

Solution 1 Device under verification (DuV) Reference Software Outcome: Verified? [Y/N] Software Attestation System Interrogate and examine 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 Outcome: Verified? [Y/N] Software Attestation System DuV

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.)

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.

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.

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

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

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

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.