Re: example: secure computing kernel needed

2003-12-14 Thread Paul A.S. Ward
I'm not sure why no one has considered the PC banking problem to be a
justification for secure computing.  Specifically, how does a user know
their computer has not been tampered with when they wish to use it for
banking access.
Paul

John S. Denker wrote:

Previous discussions of secure computing technology have
been in some cases sidetracked and obscured by extraneous
notions such as
 -- Microsoft is involved, therefore it must be evil.
 -- The purpose of secure computing is DRM, which is
intrinsically evil ... computers must be able to
copy anything anytime.
Now, in contrast, here is an application that begs for
a secure computing kernel, but has nothing to do with
microsoft and nothing to do with copyrights.
Scenario:  You are teaching chemistry in a non-anglophone
country.  You are giving an exam to see how well the
students know the periodic table.
 -- You want to allow students to use their TI-83 calculators
for *calculating* things.
 -- You want to allow the language-localization package.
 -- You want to disallow the app that stores the entire
periodic table, and all other apps not explicitly
approved.
The hardware manufacturer (TI) offers a little program
that purports to address this problem
  http://education.ti.com/us/product/apps/83p/testguard.html
but it appears to be entirely non-cryptologic and therefore
easily spoofed.
I leave it as an exercise for the reader to design a
calculator with a secure kernel that is capable of
certifying something to the effect that no apps and
no data tables (except for ones with the following
hashes) have been accessible during the last N hours.
Note that I am *not* proposing reducing the functionality
of the calculator in any way.  Rather I am proposing a
purely additional capability, namely the just-mentioned
certification capability.
I hope this example will advance the discussion of secure
computing.  Like almost any powerful technology, we need
to discuss
 -- the technology *and*
 -- the uses to which it will be put
... but we should not confuse the two.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to 
[EMAIL PROTECTED]


--

Paul A.S. Ward, Assistant Professor  Email: [EMAIL PROTECTED]
University of Waterloo  [EMAIL PROTECTED]
Department of Computer Engineering   Tel: +1 (519) 888-4567 ext.3127
Waterloo, OntarioFax: +1 (519) 746-3077
Canada N2L 3G1   URL: http://www.ccng.uwaterloo.ca/~pasward


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


CryptoPhone source and CryptoPhone for Windows released

2003-12-14 Thread Barry Wels
We published today the full source code of our CryptoPhone products at
http://www.cryptophone.de/. Also available for download is now the
first public Beta version of the free GSMK CryptoPhone for Windows
software.

The free GSMK CryptoPhone for Windows is currently in public Betatest.
Please note that some bugs may still be in there as we concentrated our
efforts primarily on the testing and debugging of our commercial
product GSMK CryptoPhone 100.

With regards,

Barry Wels

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Zero Knowledge Authentication? (was Cryptolog Unicity Software-Only Digital Certificates)

2003-12-14 Thread Anton Stiglic
 Previously used primarily in scientific/academic applications, zero
 knowledge authentication is a method of proving a user's identity without
 revealing his password to the verifier.

So anybody knows exactly what this zero-knowledge authentication is
that they use?

 Using this technology, Unicity
 allows companies to issue digital certificates securely on a software-only
 basis, eliminating the need to supply employees, partners and clients with
 special hardware, or to require them to locally store certificates on
their
 computers. The private data is never stored on the user's hard drive, and
 is erased from the RAM as soon as the user no longer needs it.

This part about storing private keys on a server is not novel.  The company
that I work for has a similar solution with respect to this, it's called
HotSign:

http://www.okiok.com/index.jsp?page=Hot+Sign

--Anton

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Swipe-Free Credit Cards Tested

2003-12-14 Thread R. A. Hettinga
http://www.cbsnews.com/stories/2003/12/12/tech/printable588346.shtml

CBSNews.com

Swipe-Free Credit Cards Tested
NEW YORK, Dec. 12, 2003


The familiar process of buying something with a credit card - handing the
plastic to the clerk or swiping it yourself, then waiting for approval and
signing the receipt - could be headed the way of the mechanical brass cash
register.

For more than a year, MasterCard and American Express have been testing
contactless versions of their credit cards. The cards need only be held
near a special reader for a sale to go through - though the consumer can
still get a receipt.

The card companies say the system is much faster and safer because the card
never leaves a customer's hand.

In some instances it's faster than cash, said Betsy Foran-Owens, a
MasterCard vice president. You're eliminating the fumble factor.

MasterCard has been testing its PayPass system mainly in Orlando, Fla. and
promises a nationwide rollout in 2004, beginning primarily at quick-service
restaurants and other places where people tend to be in a hurry.

American Express has mainly done pilot runs of its Express Pay service in
the Phoenix area, though the company expanded it to New York ferry
terminals on the Hudson River this week.

The new credit cards work much like the Speedpass system that ExxonMobil
has accepted for quick payments at its gas stations since 1997. But the
keychain fobs carried by Speedpass' 6 million users are good only at
ExxonMobil stations and a handful of other retail outlets.

In contrast, credit cards that incorporate the technology could be used
anywhere regular plastic is accepted, as long as stores install the new
readers. The card companies have worked out technical standards that would
let one reader handle multiple brands of contactless cards.

Still, you probably will leave home without one of the new cards for a
while. Forrester Research senior analyst Penny Gillespie predicts it will
take a few years for contactless cards to go mainstream.

Visa USA has developed contactless capabilities but is holding off on a
launch because consumers seem to be content using the cards they have in
their wallet, Visa spokeswoman Camille Lepre said.

The new cards have chips imbued with radio-frequency identification, or
RFID, the technology that Wal-Mart, the military and other institutions
hope to begin using soon to precisely track inventory.

While old-fashioned credit cards store account information on a magnetic
stripe that has to be swiped, the contactless cards keep their data on
chips inside the plastic.

American Express' ExpressPay uses a keychain fob, like the ones used by
ExxonMobil Speedpass and similar to the tags in supermarket discount
programs.

I like that it's on your keychain and it's fast to use, said Kristie
Beenau, 36, of Peoria, Ariz., who has used ExpressPay for about six months
at a CVS Pharmacy and fast-food restaurants. I charge everything anyways.
Now I wave it rather than get my card out. It's more convenient.

MasterCard's PayPass comes on a regular-sized card that also has a magnetic
stripe for swiping if need be. MasterCard also has done tests in Dallas
with Nokia Corp. in which the RFID chip is embedded in the plastic casing
of a cell phone.

The contactless cards have no battery or power. When they near a reader,
they are jolted to life by the reader's electromagnetic waves. A small
radio antenna in the cards instantly transmits account information to the
reader.

The transaction then proceeds through the credit card network just as if
the card had been swiped.

In theory, the transaction could be intercepted without a consumer's
knowledge by a technologically savvy thief intent on cloning a card. That's
because RFID transmissions themselves are not encrypted.

However, the thief would have to get quite close to his target or have a
very sensitive reader.

Also, the account number on the contactless cards is useful only in the
RFID system - it's not the same as a user's credit card number. A crook
would thus not be able to use the card number to go on a fraudulent
Internet shopping spree, for example.

There would be other hurdles.

American Express makes the RFID reader verify the card's authenticity with
a challenge-response exchange that depends on 128-bit encryption encoded
on the chip. That strength of encryption is considered safe against brute
force attacks, in which a hacker tries every possible combination.

MasterCard says it uses a different security system but would not provide
specifics.

I have some faith in the credit card companies, said Henry Holtzman, a
research scientist at the Massachusetts Institute of Technology's Media Lab
who started Presto Technologies Inc., a now-defunct company that sought to
develop in-home applications for RFID tags on consumer products. I trust
them because fraud is a serious issue they have to deal with.

Others are more skeptical. Simson Garfinkel, another MIT researcher who
follows RFID, said credit 

PKI root signing ceremony, etc.

2003-12-14 Thread Rich Salz
Some folks here might be interested in
   http://webservices.xml.com/pub/a/ws/2003/12/09/salz.html
which walks through a secure, auditable root keygen and signing ceremony.
The context is using OpenSSL to build a PKI so that we can write an XKMS
server, building up to secure Web Services messages using XML DSIG and
Encryption.

But hey, ya gotta start somewhere.
/r$


--
Rich Salz  Chief Security Architect
DataPower Technology   http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Zero Knowledge Authentication? (was Cryptolog Unicity Software-Only Digital Certificates)

2003-12-14 Thread Joseph Ashwood
- Original Message - 
From: R. A. Hettinga [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, December 10, 2003 8:47 AM
Subject: Zero Knowledge Authentication? (was Cryptolog Unicity
Software-Only Digital Certificates)


 Launch Marks the First Commercial Use of Zero-Knowledge Authentication

I've snipped the rest, because it is primarily not useful beyond this. They
are highly incorrect about their lauch being the first commercial use of
ZKA, as a matter of fact I was involved in implenting one for commercial
use, and I was a part of a mandatory workfoce reduction (aka laid off)
from that company 2 1/2 years ago. I will admit we never referred to it as
Zero Knowledge Authentication which just sounds like a mass of crap thrown
together to sound geeky. Instead we used zero knowledge proof of knowledge
(in particular a PIN), and used that proof to provide authentication. I can
also tell you that if you're dealing with some high security requirements
(such as the claim of high security in the press release), there are some
very tricky situations and I found a number of unpublished attacks against
such systems (all were addressed before the product shipped, except the one
I address below which is inherent). So to anyone looking at such a system, I
recommend that they give it at least 2 years to mature and be attacked, and
even then make sure that a number of worthwhile names have actually looked
at the protocols involved, and the implementation.

With that said, I see little reason that such systems need to exist, you
continually end up coming back to but what is it actually good for the
truth is that with a small piece of knowledge, only a small number of
accounts need their existance known to compromise the system. An example,
simple PIN-based system, e.g. ATM bank card network, PIN must be at least 4
digits, and a maximum of 6. First, statistically the vast majority of PINs
will be 4 digits. Now contrary to reality, we will assume that the pins are
chosen randomly (most people choose a pattern). The fact is that with 4
digits there are only 10,000 possible pins, so only 5000 guesses need to be
made to on average have broken into one account. From there the standard is
that each account is given 3 guesses before disabling, so only 1667 cards
have to be uncovered in order to break into an account. Now realistically,
how long will this take? Here in the US ATM cards can be uniquely identified
by 16 digits (it's been linked into the Visa network), this makes acquiring
the card number easy. Acquiring the number of 1667 cards is almost trivial.

On such high security systems, they invariably have further problems. The
base information required for a user to log in can be downloaded free of
security (for roaming), this allows an attacker to simply download all the
login credentials for the entire enterprise. In many cases large companies
will have more than 1667 people who have root access on the network. This is
a fatal flaw for the design, and unfortunately for such systems this is a
flaw that cannot be addressed except by switching to passphrases, something
that would lower their usability (their biggest selling point) to the same
level of all other secure systems.
Joe

Trust Laboratories
Changing Software Development
http://www.trustlaboratories.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: example: secure computing kernel needed

2003-12-14 Thread Bill Stewart
At 02:41 PM 12/14/2003 +, Dave Howe wrote:
Paul A.S. Ward wrote:
 I'm not sure why no one has considered the PC banking problem to be a
 justification for secure computing.  Specifically, how does a user
 know their computer has not been tampered with when they wish to use
 it for banking access.
I think PC banking is an argument *against* Secure Computing as currently
proposed - there is no way to discover if there is a nasty running in
protected memory or removing it if there is.
Agreed.  It's a better argument for booting from a known CDROM distribution.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Postgraduate programs

2003-12-14 Thread David M


On Fri, 12 Dec 2003, Anton Stiglic wrote:

 government policies on several countries and knowing your suggestions on
 good schools is a key component for my paper.

 You can start by looking here:
 http://hcs.harvard.edu/~dmolnar/gradschools.html

Thanks for mentioning my list! I've recently moved to UC-Berkeley, so the
most current version will be here:

http://www.cs.berkeley.edu/~dmolnar/gradschools.html

I should caution, however, that I make no attempt to rank or order
programs (except to put Berkeley and Harvard first since I went there).
Also, I only update the list when people send me e-mail corrections, so it
is possible that it's out of date. Any corrections or updates are welcome.

thanks,
-David Molnar

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: example: secure computing kernel needed

2003-12-14 Thread Anne Lynn Wheeler
At 07:25 PM 12/11/2003 -0500, Paul A.S. Ward wrote:
I'm not sure why no one has considered the PC banking problem to be a
justification for secure computing.  Specifically, how does a user know
their computer has not been tampered with when they wish to use it for
banking access.
actually the EU FINREAD (financial reader) standard is quite directed at 
this area. basically a secure entry/display\token-interface device. part of 
the issue is not skimming any pin-entry that may be assumed as possible 
with just about all keyboard-based entry (aka tamper evident device  
supposedly somewhat consumer equivalent of the TSM ... trusted security 
module and tamper evident guidelines for point-of-sale terminals). In 
effect, finread is isolating some set of secure components into a tamper 
evident housing that has something akin to a trusted security module.

the other aspect somewhat shows up in the digital signature area. 
fundamentally a digital signature may be used for authenticating (and 
message integrity) ... but not, by itself as to agreement in the legal 
signature sense. the issue is how to create an environment/infrastructure 
for supporting both straight-forward authentication as well as 
intention/agreement

in theory finread has the ability to securely display the value of a 
transaction (and possibly other necessary details) and then requires a PIN 
entry after the display as evidence of

1) something you know authentication
2) being able to infer agreement with the transaction.
pretty much assumed is that finread implies some sort of token acceptor 
device ... which in turn implies a something you have token authentication.

so finread is attempting to both address two-factor authentication (and 
possibly three if biometric is also supported) as well as establish some 
environment related for inferring agreement/intention/etc as required per 
legal signature.

possibly overlooked in the base eu finread work is being able to prove that 
the transaction actually took place with a real finread device as opposed 
to some other kind of environment. In the (financial standard) X9A10 
working group on the X9.59 financial standard for all electronic retail 
payments we spent some amount of time on not precluding that the signing 
environment could also sign the transaction i.e.

1) amount displayed on secure secure display,
2) pin/biometric securely entered (after display occurs)
3) token digitally signs (after pin/biometric entered)
4) finread terminal digital signs
the 2nd  3rd items (alone) are two (or three) factor authentication. 
however, in conjunction with the first and fourth items some level of 
assurance that the person agrees with the transaction.

lots of past finread references:
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? 
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication 
white paper
http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication 
white paper
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, 
here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative 
to PKI?
http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and 
their users [was Re: Cryptogram:  Palladium Only for DRM]
http://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has 
conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm15.htm#40 FAQ: e-Signatures and Payments
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel 
Borenstein: Carnivore's Magic Lantern
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security 
requested
http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security 
requested
http://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet 
Banking