One of my RSA SecureID tokens had recently expired, so I decided to do a teardown to see what is inside. While there was one such teardowns posted on EETimes a few years ago, I thought it would still be worthwhile to take it apart myself.
By design, these RSA SecureID tokens shut down and deactivate after five years. The following is a picture of the deactivated device:
SecureID was designed for maximum robustness and security and thus is extremely difficult to dissemble. The outer plastic shell is firmly glued onto the interior and I had to use pliers to peel it off little by little. After the outer case is removed, the epoxy-filled interior is revealed:
On the reverse side (see pictures blow), there are seven exposed pads. Presumably, these are used to program the device prior to activation. Different SecureID tokens are identical electronically, and the only differences among them are the initial seed values. The proprietary algorithm uses the initial seed value to determine the sequence of the generated pseudo-random numbers.
The battery SecureID uses is what seems to be a standard CR2032 lithium coin cell. When I took the it out (after being in use for more than 5 years), the battery still had enough power to light an LED. A standard CR2032 has a capacity of roughly 200mAh. So it seems that the SecureID draws less than 5 micro-amp on average. This is quite incredible!
It was very difficult to get to the circuit board out as everything was immersed in the epoxy casing. This design makes it virtually impossible to retrieve the circuit board while still maintain its integrity. All these efforts are necessary to make it more difficult to reverse engineer the device.
The circuit board contains nothing more than the bare minimum components to power a custom MCU and an LCD. As you can see in the next picture, the only component I managed to salvage intact is the crystal. I was really excited at first since the crystal frequency can reveal some crucial information on how the device operates.
Judging from the form factor of the crystal, it seems that this is a standard 32768 Hz RTC crystal. The eetimes article seemed to also suggest this.
But I was not quite convinced. The standard RTC crystal has a drift of around 6 ppm which is equivalent to roughly one second per day. This seems to be too inaccurate for a device like this as its operation is entirely dependent on the synchronization with the server. Although it is entirely possible that each time when the SecureID is used, the server checks whether the number user entered is in the immediate vicinity of the number the server has generated at the time so that server could record this discrepancy and uses it to calibrate future uses.
Or it may be that the crystal is only for the MCU. In this case, the oscillation frequency would be much higher than 32768 Hz. While crystals other than those used for RTC rarely come in this form factor, it is not entirely impossible. Unfortunately, I could not get the crystal to work using a few different methods. This could be of a few different reasons: the crystal might have been damaged during the dissembling process (which is not entirely impossible since everything had to be extracted from the epoxy); or the crystal has very strict driving requirements which my crystal testers did not meet. Either way, it is a little bit disappointing since I could not verify what that crystal was used for.