Re: [Full-disclosure] round and round they go, keys in ram are ripe for picking...
Countermeasures and their Limitations FIPS 140-1 [http://www.itl.nist.gov/fipspubs/fip140-1.htm] addresses this. [snip] *SECURITY LEVEL 4* In addition to the requirements for Security Levels 1, 2 and 3, the following requirements shall also apply to a multiple-chip embedded cryptographic module for Security Level 4. * The contents of the module shall be completely contained within a tamper detection envelope (e.g., a flexible mylar printed circuit with a serpentine geometric pattern of conductors or a wire- wound package or a non-flexible, brittle circuit) which will detect tampering by means such as drilling, milling, grinding or dissolving of the potting material or cover. * The module shall contain tamper response and zeroization circuitry. The circuitry shall continuously monitor the tamper detection envelope for tampering, and upon the detection of tampering, shall immediately zeroize all plaintext cryptographic keys and other unprotected critical security parameters (see Section 4.8.5). The circuitry shall be operational whenever plaintext cryptographic keys or other unprotected critical security parameters are contained within the cryptographic module. * The module shall either include environmental failure protection (EFP) features or undergo environmental failure testing (EFT) as specified in Section 4.5.4. [snip] Consider the IBM 4758 [http://www-03.ibm.com/security/cryptocards/pcicc/overproduct.shtml] as a good example of how it's implemented. Cheers, Michael Holstein CISSP GCIA Cleveland State University ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] round and round they go, keys in ram are ripe for picking...
On Fri, Feb 22, 2008 at 10:05 AM, Michael Holstein [EMAIL PROTECTED] wrote: ... FIPS 140-1 [http://www.itl.nist.gov/fipspubs/fip140-1.htm] addresses this. ... * The contents of the module shall be completely contained within a tamper detection envelope... * The module shall contain tamper response and zeroization circuitry. ... * The module shall either include environmental failure protection (EFP) features or undergo environmental failure testing (EFT) .. i'm fond of tamper resistant / evident packaging, but this is usually applied to persistent key storage rather than working system memory. works well for authentication tokens and such, even if these methods can also be bypassed with some effort. (see http://flylogic.net/ and their disassemblies at http://flylogic.net/blog ) tamper resistant cases are bit more fun, like the blackbox [0] pelican padlock'ed with zeroization / panic button. however, after reading this paper, it appears that secure overwrite of all key scrubbed memory and other sensitive locations would be preferable to simple power off, even if the case is a pain to open... a fun attack, to be sure. 0. DefCon 13 black box challenge http://blog.makezine.com/archive/2005/07/_defcon_the_jan.html ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] round and round they go, keys in ram are ripe for picking...
On Thu, Feb 21, 2008 at 12:43 PM, Elazar Broad [EMAIL PROTECTED] wrote: http://blog.wired.com/27bstroke6/2008/02/researchers-dis.html Lest We Remember: Cold Boot Attacks on Encryption Keys the best part is: ''' Countermeasures and their Limitations Memory imaging attacks are difficult to defend against because cryptographic keys that are in active use need to be stored somewhere. Our suggested countermeasures focus on discarding or obscuring encryption keys before an adversary might gain physical access, preventing memory-dumping software from being executed on the machine, physically protecting DRAM chips, and possibly making the contents of memory decay more readily. ''' executive summary: - don't let malware read keys from memory. (ah, security, so many holes, so many weak links...) - the ability to scrub keys out of memory is ideal, but likely fallible. can you hit that panic button fast enough? - boot from secure media. you're booting from a read-only iso into that FDE protected OS, right? - avoid pre-computation of key schedules. high throughput hardware crypto implementations are great for this. i love padlock engines... - key expansion: i'm not familiar with any FDE that does this. anyone? note that if you're not using key scrubbing in your disk encryption (loop-aes?) you've got bigger remanence problems to worry about: Data Remanence in Semiconductor Devices http://www.cypherpunks.to/~peter/usenix01.pdf ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
