Cryptovirology Implications
for Secure Hardware
Adam L. Young
joint work with Moti M. Yung
Dagstuhl Security Hardware Workshop
Our Goal
• Our goal is not to give a detailed overview of
cryptovirology.
• Instead, we will survey at a high level those
aspects of cryptovirology that might be of
interest to hardware designers.
• We will drill down into one
technologyQuestionable Encryptions
Dagstuhl Security Hardware Workshop
Road Map
• Cryptoviral Extortion –
How cryptovirology started
• Asymmetric backdoors
• Cryptocounters
• Questionable Encryption
Dagstuhl Security Hardware Workshop
The Big Picture
• Cryptographer – One who designs cryptographic
algorithms and/or cryptographic protocols.
GOAL: Defend systems + give new capabilities
• Cryptanalyst – One who breaks cryptographic
algorithms and/or protocols.
• Cryptovirologist – One who designs
insider/outsider attacks on networks, computer
systems, hardware using cryptography in new and
innovative ways. GOAL: Attack systems + give
new capabilities
Dagstuhl Security Hardware Workshop
Observation
• When antivirus analysts disassemble malware they get the keys
to the kingdom.
• The AIDS Information Trojan used a symmetric cipher to mount
a DoR attack (Denial of Resources)
– Encrypted the victim’s file names in the file system
• Our Idea: Use asymmetric crypto in the DoR attack [YY96a]
• Our Idea: break the symmetry between the antivirus analyst’s
view of the virus and the attacker’s view of the virus.
• Antivirus analyst sees a virus containing a public key.
• Attacker sees a virus plus his/her own private decryption key.
• So, only the attacker can give the victim his/her data back.
Dagstuhl Security Hardware Workshop
Assumptions for Cryptoviral Extortion
• The host computer system has valuable data D
that is not backed up (i.e., cannot be recovered
elsewhere).
• The virus has access to a secure random bit
generator
• The virus has access to a secure symmetric
cipher
• The virus has access to a secure asymmetric
cipher
Dagstuhl Security Hardware Workshop
Cryptoviral Extortion Attack
1) Attacker generates a private
key x and corresponding
public key y. Attacker places y
in virus and deploys virus.
5) Attacker obtains the ransom.
The attacker decrypts c using
x to obtain k. The key k is
sent to the victim.
2) Virus arrives on host machine
and activates. It generates a
random symmetric key k, it
encrypts D with k to obtain C,
then encrypts k with y to
obtain ciphertext c.
3) Virus deletes D and k, informs
the victim of the attack, and
gives contact information for
the attacker (e.g., a digital
pseudonym).
4) Victim contacts the attacker
and gives the attacker c along
with the ransom.
6) The victim obtains k, decrypts
C with it, and thereby recovers
D.
Dagstuhl Security Hardware Workshop
Security of the Attack
• Analyzing the code for the virus reveals the public key y,
not the private key x.
• As long as the symmetric key k is not captured (e.g., in a
core dump) in the short time that it resides on the host
machine, the attack is secure under the aforementioned
assumptions (only the attacker can recover D).
• The encryption can be performed incrementally to avoid
detection.
• Data can be extorted instead of money. The virus can store
a checksum of the desired data in c for verification.
• To assure anonymity, a mix network can be used by the
attacker to communicate with the victim.
Dagstuhl Security Hardware Workshop
Is this it?
Q: Is cryptoviral extortion the only interesting use of cryptography
in attacking systems?
A: No.
•
•
•
The power of using a public key to break the symmetry
between what the malware analyst sees and what malware
writers see compelled us to investigate other applications and
attacks.
As the attacks we identified grew in number and severity, we
came to regard this area as cryptovirology.
Dagstuhl: This same symmetry breaking has the potential to
improve the security properties of algorithms implemented in
silicon when hardware reverse-engineering is a threat.
Dagstuhl Security Hardware Workshop
Backdoor 1 in RSA Key Generation
Solution 1: Use a fixed, randomly selected RSA prime p in every
key generation device.
Logic: q is random, so the modulus n = pq “looks” random.
Break: Apply the Euclidean algorithm to two different moduli. Out
pops p.
So, this is a bad idea.
This is also a symmetric backdoor. The “key” p is in the
implementation and is also used by the attacker to exploit the
backdoor.
Dagstuhl Security Hardware Workshop
Backdoor 2 in RSA Key Generation
Solution 2: Put a 160-bit randomly chosen seed s1 in the software
RSA key generation program. Let s2 be a string representing
the current time/date and other unique + guessable info.
relating to the machine the generator is on. Apply a PRBG to s3
= s1 || s2 to derive the bits that constitute p.
Logic: Each prime p will be unique with very high probability.
Break: Disassemble the software program and extract s1.
So, this is a bad idea.
This is a symmetric backdoor. The “key” s1 is in the
implementation and is also used by the attacker to exploit the
backdoor.
Dagstuhl Security Hardware Workshop
Backdoor 3 in RSA Key Generation
Solution 3: (sketch only, [YY96b,YY97])
- place a public key Y in the RSA key generator
- generator chooses a seed s randomly
- generator encrypts s with Y to obtain c
- generator computes prime p as a cryptographic (hash) function of s
- generator encodes c in the bit representation of the RSA modulus n being
generated (subliminal channel)
- attacker extracts c from n and uses his/her private key x to recover s
Logic: Symmetry of views is broken using Y.
This is an asymmetric backdoor. The public key Y is in the implementation
whereas x is known only to the attacker that plants the backdoor.
Dagstuhl Security Hardware Workshop
Backdoor 4 in RSA Key Generation
• The state-of-the-art in asymmetric backdoors in RSA
key generation has continued to advance.
• Modern RSA asymmetric backdoors:
– Use elliptic curve cryptography. In particular they exploit
point compression to enable very small asymmetric
ciphertexts transmitted through small subliminal channels.
– Use a twisted pair of curves to enable better proofs of
indistinguishability (i.e., that a backdoored RSA modulus is
computationally indistinguishable from a “normal” or
“reference” RSA modulus) [YY05a].
– Use Coppersmith’s factoring algorithm [Co96] to achieve
added space-efficiency [CS03].
Dagstuhl Security Hardware Workshop
104 foot view of a cryptocounter
• Formal work done by Katz et al. [KMO01]
• A cryptocounter is a ciphertext of a plaintext integer
(e.g., plaintext contained in {0,1,2,…n-1}) that:
–
–
–
–
–
Is created using a “public key”
Can be incremented without first decrypting it
Can be decremented without first decrypting it
Can be incremented/decremented by anyone
Can only be deciphered by the holder of the private key
• Increment/Decrement operation uses the public key.
Dagstuhl Security Hardware Workshop
Cryptocounters continued
•
It is a like a “1-up counter” (or m-up counter) on a register
except that only the holder of the private key can read the state
of the array of flip-flops (attempt at translation for EEs).
•
Useful as a software tool for gathering statistics in an untrusted
computing environment (“honest-but-curious” threat model).
•
Katz et. al’s construction utilizes the composite quadratic
residuosity problem (decision problem).
•
The solution we describe [YY05b] employs the Paillier
cryptosystem [Pa99] and allows “re-randomization”.
•
Our counter is a value modulo n2. With a 1024-bit modulus n,
this implies that the counter is 2048 bits = 256 bytes.
Dagstuhl Security Hardware Workshop
The Drill Down – Ques. Encr.
•
Just as hardware designers fear their cores will be reverseengineered and: ripped off or tampered with…
•
Malware authors fear that malware analysts will figure out
what they are up to.
•
Question: Is it possible to design malware to exfiltrate data so
that no one can prove that it does so?
•
…even when the operation of the malware is recorded
perfectly throughout its lifetime?
•
Answer: Yes.
Dagstuhl Security Hardware Workshop
Further Thought
•
1)
2)
3)
4)
5)
6)
As cryptovirologists we must make several
worst-case assumptions:
The malware will one day be discovered
The malware will one day be reverseengineered by an analyst
The analyst is a seasoned cryptologist
Core dumps will be taken after each
instruction that the malware executes
All core dumps will be available to the
analyst
The malware will send out packets and all
packets will be available to the analyst
Dagstuhl Security Hardware Workshop
Attack Structure
• put public key in
cryptotrojan
• encrypt all plaintext
• transmit asymmetric
ciphertext over the
Internet
• transmission can be a
covert broadcast (stego,
subliminal channel, etc.)
• only attacker can identify
and decipher broadcast
Dagstuhl Security Hardware Workshop
With Microscope and Tweezers
• Analyst identifies a call to
an asymmetric encryption
function E in Trojan.
• Trojan appears to store a
public key y.
• Trojan passes all pilfered
plaintext to E along with y
to obtain ciphertexts c.
• Analyst concludes that
Trojan steals plaintext by
sending it through E.
Dagstuhl Security Hardware Workshop
Can You Say “JUMP”?
• such an analyst is possibly jumping to a conclusion
• whether or not the Trojan is transmitting the
plaintext outside the machine:
– Depends on the function E
– Depends on the algebraic structure of y
• For a carefully selected asymmetric cryptosystem it
is entirely erroneous to assume that theft is
occurring.
Dagstuhl Security Hardware Workshop
Intuition
• A public key hides the corresponding private key
– The private key is in there, you just can’t “see it”
Q: Can a public key also hide whether or not it is a real public
key?
- informally: real can be taken to mean algebraically correct as
opposed to totally incorrect
A: Yes.
• Intuitive Goal:
– Devise a key generator that produces a public key that
“looks” real, yet provably (given private information)
forgets plaintext rather than remembers plaintext (i.e.,
enciphers plaintext).
Dagstuhl Security Hardware Workshop
Academic Work
• We call such a public key cryptosystem
a “questionable encryption scheme”
[YY05b] A. Young, M. Yung, "Questionable Encryption and
its Applications," First International Conference on
Cryptology in Malaysia---MyCrypt '05, Ed Dawson,
Serge Vaudenay (Eds.), LNCS 3715, pages 210-221,
2005.
Dagstuhl Security Hardware Workshop
Background (for GM)
Dagstuhl Security Hardware Workshop
GM Cryptosystem [GM84]
Dagstuhl Security Hardware Workshop
Questionable Encryption Extension [YY04]
Dagstuhl Security Hardware Workshop
Confusion hides the true nature…
Dagstuhl Security Hardware Workshop
Drawback
• GM as described uses an |n|-bit ciphertext
to leak a single plaintext bit
• We would like a higher bandwidth
encryption method
• The Paillier cryptosystem provides this
• We give a construction based on Paillier in
[YY05b,YY06a,YY06b].
Dagstuhl Security Hardware Workshop
Notions Related to Ques. Encr.
• Oblivious Transfer [Bl81,Ra81]
• All-or-Nothing Disclosure [BCR86a,BCR86b]
• Deniable Encryptions [CDNO97]
Dagstuhl Security Hardware Workshop
Conclusion
• We showed how protection against reverseengineering is crucial to cryptovirology.
• We showed cryptovirology attacks that may
be of interest to hardware designers who
share similar anti-reverse-engineering goals.
• This hopefully connects two seemingly
distinct technology areas.
Dagstuhl Security Hardware Workshop
References
•
•
•
•
•
•
•
•
•
•
[BCR86a] G. Brassard, C. Crepeau, J. M. Robert, “All-or-nothing
disclosure of secrets,” Crypto '86.
[BCR86b] G. Brassard, C. Crepeau, J. M. Robert, “Information Theoretic
Reductions among Disclosure Problems,” FOCS ’86.
[Bl81] M. Blum, “Three applications of the oblivious transfer: Part I: Coin
flipping by telephone; Part II: How to exchange secrets; Part III: How to
send certified electronic mail,” UC Berkeley, 1981.
[CDNO97] R. Canetti, C. Dwork, M. Naor, R. Ostrovsky, “Deniable
Encryption,” Crypto '97.
[Co96] D. Coppersmith, “Finding a small root of a bivariate integer
equation; factoring with high bits known,” Eurocrypt '96.
[CS03] C. Crépeau, A. Slakmon, “Simple Backdoors for RSA Key
Generation,” CT-RSA 2003.
[GM84] S. Goldwasser, S. Micali, “Probabilistic Encryption,” JCSS, v. 28,
n. 2, 1984.
[KMO01] J. Katz, S. Myers, R. Ostrovsky, “Cryptographic Counters and
Applications to Electronic Voting,” Eurocrypt 2001.
[Pa99] P. Paillier, “Public-Key Cryptosystems based on Composite Degree
Residue Classes”, Eurocrypt ’99.
[Ra81] M. Rabin, “How to exchange secrets by oblivious transfer,” Harvard
Aiken Comp. Lab, TR-81, 1981.
Dagstuhl Security Hardware Workshop
References (continued)
•
•
•
•
•
•
•
•
[YY96a] A. Young, M. Yung, “Cryptovirology: Extortion-Based
Security Threats and Countermeasures,” IEEE Symp. on Sec. & Priv.
[YY96b] A. Young, M. Yung, “The Dark Side of Black-Box
Cryptography, or: Should We Trust Capstone?”, Crypto ’06.
[YY97] A. Young, M. Yung, “Kleptography: Using Cryptography
Against Cryptography,” Eurocrypt ’97.
[YY04] A. Young, M. Yung, “Malicious Cryptography: Exposing
Cryptovirology,” Wiley, 2004.
[YY05a] A. Young, M. Yung, “A Space Efficient Backdoor in RSA and
Its Applications,” Selected Areas in Cryptography ’05.
[YY05b] A. Young, M. Yung, "Questionable Encryption and its
Applications," First International Conference on Cryptology in
Malaysia---MyCrypt '05, LNCS 3715, 2005.
[YY06a] A. Young, M. Yung, “Hiding Information Hiding,” 8th
Conference on Information Hiding (IH ’07), 2006.
[YY06b] A. Young, M. Yung, "On Fundamental Limitations of Proving
Data Theft," IEEE Transactions on Information Forensics and
Security, 1(4), 2006.
Dagstuhl Security Hardware Workshop