From: Scott Guthery (sgutherymobile-mind.com)
Date: Mon Feb 28 2005 - 15:40:45 CST

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

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

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