tag:blogger.com,1999:blog-1489897032337705045.post4763581525649926027..comments2023-08-30T08:07:27.900-05:00Comments on Securology: Jon Callas Responds to Ed FeltenTim MalcomVetterhttp://www.blogger.com/profile/13417236190528979780noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-1489897032337705045.post-19237765751788139742008-03-11T08:30:00.000-05:002008-03-11T08:30:00.000-05:00Mike,Thanks for commenting ...You should read up o...Mike,<BR/><BR/>Thanks for commenting ...<BR/><BR/>You should read up on <A HREF="http://en.wikipedia.org/wiki/Secure_cryptoprocessor" REL="nofollow">"secure co-processors"</A> which have productized into <A HREF="http://en.wikipedia.org/wiki/Trusted_Platform_Module" REL="nofollow">TPMs</A>. I'm not sure TPMs have the I/O performance required to run all disk encryption routines through them today, but they are built around the idea of doing key storage and crypto operations in tamper resistant hardware. Look to <A HREF="http://www.cs.dartmouth.edu/~sws/pubs/comp01.pdf" REL="nofollow">Sean W. Smith of Dartmouth for some good academic work in this area</A>.<BR/><BR/>One advantage of having them separate from CPUs, from my perspective, is that a TPM/secure co-processor will not be as dynamic as normal CPUs. Since we all benefit from having a well understood implementation (including a certification/accreditation of the hardware itself) it would be a bad idea to integrate that directly with CPUs (vendors redesign CPUs way too often to go through formal validation processes). But the requirements for changing out a TPM's design won't come very often at all.Tim MalcomVetterhttps://www.blogger.com/profile/13417236190528979780noreply@blogger.comtag:blogger.com,1999:blog-1489897032337705045.post-79463914148123732082008-03-10T18:28:00.000-05:002008-03-10T18:28:00.000-05:00Here's an idea, we could all start using Apple's 1...Here's an idea, we could all start using Apple's 12" PowerBook G4 laptops. 256MB of the system RAM is hard-wired to the logic board meaning an attacker can't remove it and steal its contents.<BR/><BR/>On a more serious note, what if there were a way to always hold your crypto key in the CPU rather than in system RAM? Maybe the architecture could be extended to provide a reserved area or model-specific register, solely for holding AES keys (along with new instructions to read/write this area). Or, maybe it could be done today just by using an obscure/unused register ... some register not stored in memory as part of a context switch operation. You wouldn't even need to store the whole key there, just part of it, so that the key is not recoverable from RAM alone. For example, if you were not using the AMD-v feature, you could store an arbitrary 64-bit value in the VM_HSAVE_PA model-specific register.Mike Myershttps://www.blogger.com/profile/13937633544028558844noreply@blogger.com