A recent "self-serving" report by Phoenix Technologies indicated that
84 of attacks could have been prevented only if Device Authentication
was used in addition to user authentication.
- Evidence Abound:
Losses from stolen IDs and passwords far exceeded damages from
worms, viruses, and other attack methods not utilizing logon accounts
Vast majority of attackers, 78 percent, committed crimes from their
home computers; most often using unsanctioned computers with no
relationship to the penetrated organization
88 percent, of those crimes were committed from a home PC using
stolen IDs and passwords and following normal logon procedures.
- Link to full report:
-Their solution?
Use Trusted Platform Module to authenticate devices.
- Problem?
TPM can also be used to force DRM. (EFF and ACLU member don't like DRM
to say the least)
- Alternatives?
1) Be a sitting duck. Passwords WILL stolen and USED to cause financial
damage;
2) Use software based device authentication. e.g. Passmark as used by
Bank of America
3) Create a world-wide PKI, issue SSL certificates to machines as well
as users, and then perform client side authentication from the server.
4) Use IP addresses to perform machine authentication.
- Read more at:
Any thoughts?

Saqib Ali wrote:

A recent "self-serving" report by Phoenix Technologies indicated that
84 of attacks could have been prevented only if Device Authentication
was used in addition to user authentication.

- Evidence Abound:
Losses from stolen IDs and passwords far exceeded damages from
worms, viruses, and other attack methods not utilizing logon accounts
Vast majority of attackers, 78 percent, committed crimes from their
home computers; most often using unsanctioned computers with no
relationship to the penetrated organization
88 percent, of those crimes were committed from a home PC using
stolen IDs and passwords and following normal logon procedures.

- Link to full report:

-Their solution?
Use Trusted Platform Module to authenticate devices.

- Problem?
TPM can also be used to force DRM. (EFF and ACLU member don't like DRM
to say the least)

What about a working TMPs first? Just imagine some chip engineer with a
huge mathematical but no cryptographic background actually followed the
specification exactly, then he wouldn't have corrected key<<1024 to
key%(1<<1024) and the entire security would be reduced from 1024 to 1 bit;
well, if the chip actually worked at all, because with such a specification
just a working initialization would be a miracle.

Anyway, they're right. With such a criticial cryptographic device like a
TPM you need an absolutely trustworthy operating system in control of that
device, so Windows, especially the new one with kernel-integrated and
non-removable DRM is totally out of business for such a job.

3) Create a world-wide PKI, issue SSL certificates to machines as well
as users, and then perform client side authentication from the server.

Why world-wide? A corporate-wide PKI with issuing certificates to the users
is a feasible method.

4) Use IP addresses to perform machine authentication.

!

Any thoughts?

What about Smartcards? Similar to TPM, but not hard-wired, long-term
proven, fully under your control and exchangeable.

Sebastian Gottschalk <seppi@seppig.dewrites:
What about a working TMPs first? Just imagine some chip engineer with a
huge mathematical but no cryptographic background actually followed the
specification exactly, then he wouldn't have corrected key<<1024 to
key%(1<<1024) and the entire security would be reduced from 1024 to 1 bit;
well, if the chip actually worked at all, because with such a specification
just a working initialization would be a miracle.

Anyway, they're right. With such a criticial cryptographic device like a
TPM you need an absolutely trustworthy operating system in control of that
device, so Windows, especially the new one with kernel-integrated and
non-removable DRM is totally out of business for such a job.

there was an activity that looked at chip for the original ibm/pc
(back in the days of acorn) as a countermeasure to software piracy
to implement software licensing for specific machines similar
to what was common for mainframe software licensing recent post
mentioning
http://www.garlic.com/~lynn/2006p.html#32 T - hand-held security

however, nothing came of the anti-privacy activity at that time.

slightly related thread
http://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#5 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#6 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?

re:
http://www.garlic.com/~lynn/2006p.html#41 Device Authentication - The answer to attacks lauched using stolen passwords?

for slight other drift, i gave a talk on assurance and aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads

in the TPM track at the spring 2001 intel developer's forum
http://www.garlic.com/~lynn/index.html#presentation

some comments on the talk from that time
http://www.garlic.com/~lynn/aadsm5.htm#asrn1
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aadsm5.htm#asrn4

the person heading up the tpm effort was in the front row and i
quipped that after the past couple years the tpm chip design was
starting to now look more and more like aads chip strawman and he
quipped back that it was because I didn't have a committee of 200
people helping design/specify the chip.

Saqib Ali wrote:
A recent "self-serving" report by Phoenix Technologies indicated that
84 of attacks could have been prevented only if Device Authentication
was used in addition to user authentication.

- Evidence Abound:
Losses from stolen IDs and passwords far exceeded damages from
worms, viruses, and other attack methods not utilizing logon accounts
Vast majority of attackers, 78 percent, committed crimes from their
home computers; most often using unsanctioned computers with no
relationship to the penetrated organization
88 percent, of those crimes were committed from a home PC using
stolen IDs and passwords and following normal logon procedures.

- Link to full report:

-Their solution?
Use Trusted Platform Module to authenticate devices.

- Problem?
TPM can also be used to force DRM. (EFF and ACLU member don't like DRM
to say the least)

- Alternatives?
1) Be a sitting duck. Passwords WILL stolen and USED to cause financial
damage;
2) Use software based device authentication. e.g. Passmark as used by
Bank of America
3) Create a world-wide PKI, issue SSL certificates to machines as well
as users, and then perform client side authentication from the server.
4) Use IP addresses to perform machine authentication.

- Read more at:

Any thoughts?

I think some problems should be considered:
(1) Privacy: using such device authentication, every things that
everyone do can be recorded.
(2) System cost: security solution always consume many system
resources. if each operation of each computer should authenticated,
what will happen? Should a router authenticate each tcp packages
passing it?
(3) Convenience: in fact many existing systems have mature security
measurements but for convenience they are usually abandoned and
reversely these system are blamed for security risk (such as domain
server authentication and administration in WIN 2000/XP)
(4) How to prevent cheating of device: an hacker may imitate the tcp
packages he get from the network, etc.

Single point of failure.
How so? Please explain.
Saqib

Lassi Hinen <lahippel@ieee.orgies.invalidwrites:
If you loose the device, you are in trouble, because you loose all
services that are bound to that device.

It might be possible to subscribe to services with several redundant
devices, but that will cause problems with synchronization, DRM,
subscription cost, or any combination of the above.

re:
http://www.garlic.com/~lynn/2006p.html#41 Device Authentication - The answer to attacks lauched using stolen passwords?
http://www.garlic.com/~lynn/2006p.html#4 Device Authentication - The answer to attacks lauched using stolen passwords?

there have been numerous discussions in the past regarding unique
authentication tokens per service vis-a-vis a single (or small
number) of authentication tokens where an individual token is used
for multiple different services.

frequently this is associated with an institutional-centric paradigm
where each institution/service provides their own unique token
w/o even offering the end-user a choice.

however, some number of studies have turned up that in the majority of
the institutional centric paradigms then end-users are managing
the tokens as a unit and the most common failure mode will involve
all such tokens aka credit cards all in the same wallet/purse (the
most common lost/stolen scenario is the wallet/purse involving all
such authentication tokens).

various past posts on institutional-centric paradigms vis-a-vis
person-centric paradigm where the individual has a choice on how
many tokens they choose to carry and which tokens are bound to
which services.
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb?
http://www.garlic.com/~lynn/2004q.html#0 Single User: Password or Certificate
http://www.garlic.com/~lynn/2005g.html#8 smartcards and card readers
http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and RM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005p.html#6 Innovative password security
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as IS 18000-6C
http://www.garlic.com/~lynn/2006p.html#32 T - hand-held security