The Secustick exposed
As it turned out, we already had full access to the 'protected' files. Apparently, the program merely checks to see if the password has been entered correctly, and the stick's contents are unlocked on the basis of this. By simply altering the return value of the VerifyPassWord() routine, the - unencrypted - data is revealed.
Checking the password and unlocking the files are two separate processes. This is arguably a serious design error. The most secure sticks execute both encryption and unlocking on the chip. A somewhat less secure method consists in comparing an encrypted password that resides in the controller with one that is stored on the pc. This will at least prevent the password from being harvested from the flash memory. Less secure still is storing it in the stick's memory, since that can lead to the password being read from the chip. The Secustick is another step lower on the ladder: the processes of checking the password and unlocking the stick are executed entirely on the pc - a machine that is obviously beyond one's control in the event that the stick gets stolen.
Checking the password and unlocking the files are two separate processes. This is arguably a serious design error. The most secure sticks execute both encryption and unlocking on the chip. A somewhat less secure method consists in comparing an encrypted password that resides in the controller with one that is stored on the pc. This will at least prevent the password from being harvested from the flash memory. Less secure still is storing it in the stick's memory, since that can lead to the password being read from the chip. The Secustick is another step lower on the ladder: the processes of checking the password and unlocking the stick are executed entirely on the pc - a machine that is obviously beyond one's control in the event that the stick gets stolen.
Next page (Concluding remarks - 6/6)
