on thursday NUMBER september NUMBER NUMBER NUMBER michael mckay wrote on tue sep NUMBER NUMBER at NUMBER NUMBER NUMBERpm NUMBER yannick gingras wrote this make me wonder about the relative protection of smart cards they have an internal procession unit around NUMBERmhz can we consider them as trusted hardware smartcards do not have fixed clock rates more often than not as the iso spec dictates that they are externally powered and clocked but smartcards used for security purposes usually javacards have built in crypto co processors that make clock rate irrelevant NUMBERmhz smartcards can often preform triple des faster than general purpose processors clocked at ten times the speed that said clock rate has nothing with how trustworthy a card is as michael pointed out there s something of an arms race between manufacturers and attackers which has nothing to do with clock rate and time and time again what we ve seen is that it s not a question of is it secure it s a question of who is it secure from and for how long security is rarely a question of absolutes despite the often boolean nature of a break rather it s a question of assessing quantifying and managing risk smartcards are designed to address threats in which the cost of protection cannot exceed the NUMBER NUMBER range depending on the application as whether or not they are trusted hardware the question again revolves around attacker and timeframe one might expect a bored undergrad ee student to have more trouble revealing the contents of a pilfered smartcard than say a governtment intelligence service if your goal is to keep undergrad ees from perpetrating mass fraud in the caffeteria then a smartcard is likely trustworthy enough for your application if your aim is to protect icbm launch codes then it s probably the wrong tool in either application a risk cost ratio must justify the use of the protection measure in question alex russell alex URL alex URL 