Software Certification and Attestation Rajat Moona Director General, C-DAC.
-
Upload
lorin-wheeler -
Category
Documents
-
view
220 -
download
0
Transcript of 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 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.
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.
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
AA BB
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.