How do RSA SecureID ® Keys Work?
Yes it does work as you say. The chip is "tamper resistant" and will erase the "seed" (secret key) if any attempt is made to attack it. This is often accomplished by having a non-user-replaceable battery and a "trap" that breaks power to the device once the device is opened, or the chip surface is removed. The key is then stored in a SRAM, requiring power to keep the key.
The key is a seed, that combined with the current time in 60 second step (effectively, the current UNIX timestamp / 60), refreshes the code.
No, the device does NOT need to be precise. Instead, the server will store the time of the last accepted code. Then the server will accept a code one minute earlier, one minute ahead, and at the current time, so if the current time at server is 23:20, then it will accept a code from 23:19, 23:20 and 23:21.
After this, it will store the time of the last accepted code, eg if a 23:21 code was accepted, it will store 23:21 in a database, and refuse to accept any code that was generated at 23:21 or earlier.
Now to the interesting part: To prevent an imprecise token from desynchronizing from the server, the server will store in its database, if it was required to accept a 23:19 code or a 23:21 code at 23:20 time. This will ensure that at next logon, the server will correct the code with the number of steps.
Lets say you at Clock 23:20 login with a 23:19 code. Server stores "-1" in its database (and if it would be a 23:21 code, it would store "+1" in database). Next time you login, Clock is 23:40. Then the server will accept a 23:38, 23:39 or 23:40 code. If a 23:38 code is accepted, it will store "-2" in database, at 23:39 it will keep "-1" in database, and at 23:40 it will store "0" in database.
This effectively makes sure to keep the server synchronized to your token. On top of this, the system, if a token "ran too far away" from the server (due to it being unused for a long time), allows resyncronization. This is accomplished either by a system administrator, or a self service resynchronization service is presented where the token user is asked to provide 2 subsequent codes from the token, like 23:20 and 23:21, or 19:10 and 19:11. Note that the server will NEVER accept a token code generated at or prior to the time that "last used token code" was (as this would allow reuse of OTP codes). When a resyncronization is done, the token will store the difference from the provided 2 token codes, and the current server time and in a resync, the search window could be like plus/minus 50 steps (which would allow about 0,75 hours of desync in both directions).
The server can detect a desynchronized token by generating the 50 prior codes and 50 future codes, and if the specified code matches that, it will launch the resync process automatically. Many times, to prevent an attacker from using the resync process to find valid codes, once an account is in resync mode, login will not be accepted without resyncing, which would require the attacker to find the exact code subsequent or prior to the code just found.
The SecurID token has a "seed" value assigned to it, and is programmed with a specific algorithm that generates numbers based on the seed and its system clock. The seed value is also stored in a file that is shipped with the token. Upon receiving the token, System Administrators import the seed file to the authentication server. Since the SecurID token device and the server both have the seed value, and both are using the algorithm, the server can determine what the correct token code should be at any given time.
Occasionally, the token's clock may come out of sync with the authentication server. If this happens, System Administrators or other authorized support personnel can assist the user by performing a re-synchronization process on the server. This will configure the server to recognize the time offset for that token so that future authentication attempts should be handled accurately.
Note: Because these numbers must be predictable by the server, based on only the data stored in the seed file, the current time, and a standard algorithm, they can also be predicted by an attacker with special tools and access to the token. (Or worse, access to the seed files themselves - as is suspected to have happened in 2011.) Given enough consecutive token codes, there are tools that can determine the seed value and then generate future codes on their own.
The Sebastian answer was terrific. I will restate that in layman's terms. The SecureID token is simply a clock with a seed value in it. Instead of displaying time it displays a number. The dot in that we can see in the picture is seconds (I think), the bar is when the number is going to change so you can time it. If it is reaching the bottom it is about to change and if you are typing it in, you will want to wait.
The "seed" is also on the server that is authenticating the device. When security guys install the RSA server they have to load the same seeds into the server that will be receiving your pincode.
So... Basically it is a cryptoclock. Just like the old LCD watches that my kids have with dora, or princesses on them. The difference is the seed that provides the math for the number.