From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Choate To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: secret stuff In-Reply-To: <7f12be27838fe817d6ac1c35a381be46@plan9.bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sun, 16 Jun 2002 00:10:43 -0500 Topicbox-Message-UUID: af1dacfe-eaca-11e9-9e20-41e7f4b1d025 On Sat, 15 Jun 2002 presotto@plan9.bell-labs.com wrote: > Perhaps calling this a smart card is too charged? > > I don't know what miller meant but I thought > the smart card would be running the same > PAK protocol that a remote secstore server would. > You'ld just be taking via 9P over a local bus rather than > via TCP over the net. You could > snoop the conversation but it wouldn't be any different > than snooping the conversation to a secstore running > elsewhere on the network. I really don't understand > this ``mount it (and make an image - probably in less > than 10 minutes).'' Was this predicated on the card > just looking like a file system full of secrets? Under Styx-in-a-Box my Minstorms robot shows up as a directory with various devices listed as files. One can then use simple scripts and a list of device commands/codes and with simple cat and pipe style features create a quite interesting Lego based robot. I understood him to mean that the card would provide some services exported from the smart cards memory as a file system using something like Styx. This implies a deamon. Such a deamon can be cracked or subverted. In fact, I don't even need the smart card. All I need is a description of the protocol, a tap (ie MITM), time, computing power, and luck (lots if the protocol is good) to attack such a systems security. So it's really a poor example for what we're talking about. What I had in mind was such that we hood the smart card to a dumb terminal via a short serial cable and a network cable. The entire system, network stack, etc. is stored on the card. One uses some sort of mechanism to prevent the card from being directly put into debug mode (eg have the card disable the debug features through write only RAM). The point of the exercise has two targets. Unless you hit both you've a hole in your bucket; Data, Program. The question becomes "How does one get data out of the card with enough coherence to understand what is being computed?" The point is to 'glitch' the appropriate registers into a mode thay normaly would not be in. There are other attacks based on the architecture-geometry-geography relationship between the logical function of a cpu and the physical arrangement of those components. That is where high intensity optical attacks, voltage jitter (over, under, spike, pulsed, whatever they think up next week), rf skin effect forcing a charge bleed to occur, etc. > The keystroke attack is certainly there both with and without the > smartcard, they're unrelated. It depends, does the card generate the various certificates or does it take one and execute a process on it? The first is much more secure than the second, but has a timing issue related to certificates at both ends matching - a framing issue (ie consider a dropped packet w/ one cert/packet). > If you only type it in at boot time > keystroke attacks are less likely, no app code running. A keylogger isn't a program. -- ____________________________________________________________________ When I die, I would like to be born again as me. Hugh Hefner ravage@ssz.com www.ssz.com jchoate@open-forge.org www.open-forge.org --------------------------------------------------------------------