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

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
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3352
Published: 2014-08-30
Cisco Intelligent Automation for Cloud (aka Cisco Cloud Portal) 2008.3_SP9 and earlier does not properly consider whether a session is a problematic NULL session, which allows remote attackers to obtain sensitive information via crafted packets, related to an "iFrame vulnerability," aka Bug ID CSCuh...

CVE-2014-3908
Published: 2014-08-30
The Amazon.com Kindle application before 4.5.0 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

CVE-2010-5110
Published: 2014-08-29
DCTStream.cc in Poppler before 0.13.3 allows remote attackers to cause a denial of service (crash) via a crafted PDF file.

CVE-2012-1503
Published: 2014-08-29
Cross-site scripting (XSS) vulnerability in Six Apart (formerly Six Apart KK) Movable Type (MT) Pro 5.13 allows remote attackers to inject arbitrary web script or HTML via the comment section.

CVE-2013-5467
Published: 2014-08-29
Monitoring Agent for UNIX Logs 6.2.0 through FP03, 6.2.1 through FP04, 6.2.2 through FP09, and 6.2.3 through FP04 and Monitoring Server (ms) and Shared Libraries (ax) 6.2.0 through FP03, 6.2.1 through FP04, 6.2.2 through FP08, 6.2.3 through FP01, and 6.3.0 through FP01 in IBM Tivoli Monitoring (ITM)...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.