Software Certification and Attestation

Rajat MoonaDirector 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 examineSAS 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 DeviceReference 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(KAB, rA)

Authentication

• Assume Secret existence at two sides

A B

Send rA

KABKAB

Send rB

Send E(KAB, 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.

Thank You