Perimeter
12/29/2011
04:33 PM
Taher Elgamal
Taher Elgamal
Commentary
Connect Directly
RSS
E-Mail
50%
50%
Repost This

More About Software Tokens

When software tokens are as strong as hardware ones

My recent post on software tokens generated interesting feedback. I wanted to elaborate a bit more on how soft tokens can be, in fact, as strong as hardware tokens -- perhaps even better in terms of security.

It is important to decide which threats we are protecting from. If we are interested in protecting against malware that tracks memory locations and is capable of obtaining the secrets from memory while a program is executing, then storing the secret keys in software or hardware tokens would not yield the desired protection. In fact, there is no difference between the security of either model. The only way to protect against this type of malware is to execute any operation using the secret in a trusted environment.

If protecting against cracking a password that was used to decrypt an encrypted key file, then solutions are available that make software and hardware tokens equivalent in terms of security.

I encourage readers to check out the Arcot systems scheme. Arcot is now part of CA Technologies, actually. Its scheme protects secret keys as well as OTP seeds and the like in a way that prevents an attacker who has access to the stored encrypted files from obtaining the secrets.

Recognized in the industry as the "inventor of SSL," Dr. Taher Elgamal led the SSL efforts at Netscape. He also wrote the SSL patent and promoted SSL as the Internet security standard within standard committees and the industry. Dr. Elgamal invented several industry and government standards in data security and digital signatures area, including the DSS government standard for digital signatures. He holds a Ph.D. and M.S. in Computer Science from Stanford University.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Ian Farquhar
50%
50%
Ian Farquhar,
User Rank: Apprentice
1/12/2012 | 2:01:42 AM
re: More About Software Tokens
If a threat model includes a malicious entity which can read memory, there is still a very significant difference between hard and soft tokens.

For a hard token, that entity will be able to access a single derived token code.- That token code will be useful for a single authentication session.- Where the token code function includes time, this further limits the usefulness of the token code.

For a soft token, the seed/keying material will be in memory, where it is vulnerable.- When captured, it facilitates on-going use which could generate on-going valid token codes.

Consequently, I believe that the statement "there is no difference between the security of either model" is dubious.

Finally, I was wondering if Dr. ElGamal would like to comment on Wikipedia's claim that he is an advisor to Arcot Systems.- As Dr. ElGamal is encouraging readers to evaluate their products, I would think that disclosure to be appropriate.

Full disclosure: I am an employee of RSA working as a technology advisor, although my comments above are my own.
RichieB
50%
50%
RichieB,
User Rank: Apprentice
1/8/2012 | 12:05:04 PM
re: More About Software Tokens
There is an important difference between software and hardware
authentication tokens: uniqueness. Software tokens can be copied and
misused afterwards. Always. The Arcot system seems to be resistant
against brute force attacks, which is great. This means the password
will need to be stolen along with the key files. This can be done using
malware, keyloggers, etc.

I agree that using a hardware
token on a compromised system leaves the session vulnerable after
authentication. But you can rest assured that when you remove the token
and power off the computer, nobody can do a fresh authentication
pretending to be you without physical access to that token. Because by
design, the secret key material inside the hardware token cannot be
copied.

So in environments where you need to be 100% sure
that the person authenticating is someone you know, and not someone who
made a copy of the key material, use a hardware PKI token. And make sure
lost or stolen tokens are reported and disabled immediately.
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-1421
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Craig Knudsen WebCalendar before 1.2.5, 1.2.6, and other versions before 1.2.7 allows remote attackers to inject arbitrary web script or HTML via the Category Name field to category.php.

CVE-2013-2105
Published: 2014-04-22
The Show In Browser (show_in_browser) gem 0.0.3 for Ruby allows local users to inject arbitrary web script or HTML via a symlink attack on /tmp/browser.html.

CVE-2013-2187
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Apache Archiva 1.2 through 1.2.2 and 1.3 before 1.3.8 allows remote attackers to inject arbitrary web script or HTML via unspecified parameters, related to the home page.

CVE-2013-4116
Published: 2014-04-22
lib/npm.js in Node Packaged Modules (npm) before 1.3.3 allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names that are created when unpacking archives.

CVE-2013-4472
Published: 2014-04-22
The openTempFile function in goo/gfile.cc in Xpdf and Poppler 0.24.3 and earlier, when running on a system other than Unix, allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names.

Best of the Web