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: [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]>
To: "MuscleCard Mailing List" <[email protected]>
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" <[EMAIL PROTECTED]>
To: "MuscleCard Mailing List" <[email protected]>
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
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
