From: Anders Rundgren (anders.rundgrentelia.com)
Date: Tue Mar 01 2005 - 07:26:44 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Scott,
The future of the two combatting visions is IMO only to a limited extent
a security issue. The commercial issues are currently much worse.
Unfortunately neither side has currently much to offer but misery.

I'm trying to raise a political movement for getting a functional client
solution because it seems that this is needed. In "my camp" that means
trying to get _governments_ to agree on an open multi-ID solution.

That is, it is the end-user (or the end-user's employer) that should "own"
the "ID-container" not the government, bank or operator.

The "card camp" is much associated with the financial industry that
also takes pride in locking customers in the same way as operators do.

Anders

----- Original Message -----
From: "Scott Guthery" <>
To: "MUSCLE" <musclelists.musclecard.com>; "MUSCLE" <musclelists.musclecard.com>
Sent: Monday, February 28, 2005 22:40
Subject: RE: [Muscle] .Net remoting channel, muscle://

Anders:

1) The telecoms -- including Telia I''ll wager -- regularly download SIM applets with Cardholder PIN authorization so not only is
there no "user in the loop" but the operators can read and send back to themselves whatever you put on your phone or in your SIM
without you ever knowing it and regardless of what protection you think you've put on it. There are parts of the world where this
is known as identity theft.

2) If you've ever tried to build a J2ME application you'd know that there is no evidence whatsoever that Nokia or Motorola creates
better code than Microsoft or IBM. At least Microsoft asks you if you want the update. The handset manufacturers in collusion with
the operators just push it to your handset whether you like it or not.

And you want me to trust these people?

Cheers, Scott

-----Original Message-----
From: muscle-bounceslists.musclecard.com on behalf of Anders Rundgren
Sent: Sun 2/27/2005 4:05 PM
To: MUSCLE
Cc:
Subject: Re: [Muscle] .Net remoting channel, muscle://

Another, somewhat related thought experiment:

http://web.telia.com/~u18116613/TheUniversalAccessControlCard.pdf

Anders R

----- Original Message -----
From: "Peter Williams" <home_pwmsn.com>
To: "MuscleCard Mailing List" <musclelists.musclecard.com>
Sent: Sunday, February 27, 2005 05:14
Subject: [Muscle] Re: .Net remoting channel, muscle://

Lets go a bit further with the thought experiment about muscle applets, and
libmusclecard APDU plugins, in the world of .NET smartcards, TPMs, and
offcard applications implemented as .NET assemblies.

Assume a smartcard manufacturer uses ".NET chip" - one whose microcode
natively performs the MSIL instruction set. That is, there is a common
language runtime and API library, implemented in MSIL, executing
customer-generated MSIL assemblies natively. Perhaps, the chip even has its
microcode optimized for MSIL. Assume, now, that MSIL assemblies have pre-
and post-loading security properties like JavaCards - wherein a
user-generated but pre-loaded assembly might subclass the CLR runtime's own
behavior - to add a crypto service provider, for one example, add a .NET
remoting channel, for another, and configure the channel's data security
scheme for national requirements, in a yet third option.

Assume now that Intel, AMD and Sony/Hitachi add three items to their
motherboard chipsets: the bus support for TCPA delegation controls, a
secure storage compartment whose control is delegated to the TPM, and an
MSIL interpreter that creates another hardware compartment - one that
sandboxes the Pentium's own emulation of an MSIL machine from non-managed
OS and traditional Bios and ACPI/"monitoring" code. Lets also assume
Transmeta similarly field download new microcode to their chips, also, to
the same effect, with a TPM function built in, perhaps. Assume Sony
motivate this with a DRM pitch, and next generation DVD writers come with
DSPs suitably equipped for enforcing these issues, at the codec level.

Lets assume now that the TPM plays the role it was always intended to
perform (and I remember seeing some of the very first silicon masks in
1997) - limit access to critical hardware functions to only managed code
((i.e. _emulated MSIL_ code, today) . And now lets assume that a .Net
smartcard supports PCSC v2 service enumeration interfaces and hosts a .NET
implementation of the muscle applet (with Indigo-binary-encoded soap apdu
formatter, working with a similar APDU serialization module in a new
libmusclecard plug-in).

Perhaps, now we can put 2 and 2 together, and see if it makes 4. Lets
assume that the .NET Framework v2 applies the new ipc:// channel for all
communications between the managed code on the local host and the muscle
applet on the .NET smartcard access over an untrusted CCID USB link - whose
((*) some how tobetrusted ) enumeration process registers the card as an
OS-managed system resource. This would allow conventional
Intel-motherboard/Microsoft-OS system cooperation to treat the card as a
local device, and thus the ipc:// channel can facilitate remoting, given
the code security architecture could treat this as a _local_ system data
transfer. (**)

The thorn in the logic here so far, is that while the tcp:// channel now
has SSPI-based security service support in this remoting channel, the IPC
channel is not yet secured, presumably to allow subclassing by board
processor, and .Net pre-issuance packages. And this can occur on a national
basis, to suit government access to goings on your PC, and your card.
Assuming Global Platform is implemented on the .NET smartcard, as it was
supposed to implemented on the Windows Smartcard, this would be one scheme
for "contract data" security.

Ok, I think 2+2 still equals 4, so long as + is now overloaded to add
national scheme for the data security protocol to the remoting channel.
Should the contract data be soap XML encoded, the scheme could also be the
WS-security infrastructure. If its Indigo encoded binary soap, it could be
a private security scheme shared and licensed only amongst TCPA members,
and requiring the TPM to be monitoring the cooperating between Pentium and
smartcard.

If I was architecting an Intel-style horizontal infrastructure solution,
this is what I'd do! so perhaps we should play along, so open source Linux
is not too put out in this world. Keeping a foot in the door, will prevent
it being shut out (per the paranoid fears of the anti-TCPA camp) One
assumes IBM would support the open source Linux position in the TCPA
backrooms, and keep open source being locked out of this brave new world,
whilst getting trusted buses out there to the benefit of all.

At a theoretical level, this is all really an application of the
Interconnection Rule, for multilevel integrity levels:
http://www.radium.ncsc.mil/tpep/library/rainbow/NCSC-TG-011.html#HDR6.2%20%20%203%2057

(*) Need to review CCID standards proposals for clues, here.
(**) RDS or H.223 would need to addressed by Microsoft, also, for both
wired and wireless codecs, so RDS-remoted access to the local PCSC daemon
is still treated as a local transfer by the reference monitor).

----- Original Message -----
From: "Peter Williams" <home_pwmsn.com>
To: "MuscleCard Mailing List" <musclelists.musclecard.com>
Sent: Friday, February 25, 2005 9:10 PM
Subject: .Net remoting channel, muscle://

..

> I'd guess that implementing such a channel will take about 6 months to
> deliver, requiring about 1 months actual work and 5 months knowhow
> collection. The net benefit is that we move the muscle cardedge beyond
> being APDU-signalled object, integrating with applications via the
> ICardEdge. It becomes a .Net remoting partner, subject to contracts and
> policy enforcement in concert with the the wider security framework that
> applies to the application objects that will increasingly solicit its
> (distributed) services.
>
> Peter.
_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]