From: Peter Williams (home_pwmsn.com)
Date: Fri Feb 25 2005 - 23:10:13 CST

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

Now that we - in our enterprise - have finally have got critical mass to
delivery our USB smartcard products (wireless bus and wired bus tokens)
featuring muscle cardedge instances in GP security domains, we have finally
got around to architecting the system security model we were seeking to
address all along. Finally, we need worry no more about EEPROM, APDUs, USB
or applet loading policies! Thats done.

In the .Net managed code world - which apes the architecture which Li Gong
documented from the various contributions to the the Java 2 world - the
system security model links assemblies to permissions (and thus
programmable exceptions handlers), and links the permission grant model to
the channel over which the assemblies code arrives at the TCB. Once granted
operating privileges, IPC between assemblies is also subject to a
channel-based policy, in which the channel's security services control how
data is securely remoted between application processes, using managed code.

Today, Microsoft delivers two system-wide remoting channels, in the .Net
Framework: http://, tcp://: and one can register one's own in v2: w.g.
singleshot https over udp, for uPnP remote management.. Thus, one's own
"channel" can use custom security protocols that enforce the custom
application domain's specific security model. As with any channel, this
controls the data flow between objects, and the securty services to be
applied to and enforced upon any flows over that remoting channel.

With the arrival of the .Net smartcard, we should perhaps apply focus to
this issue area, and upgrade the muscle cardedge's feature set - to support
a custom remoting channel that allows the cardedge object to be accessed
over a "muscle" .Net remoting channel. Naturally, one would use GP security
services to secure the flow of data between cardedge'd objects, and the
data flows being controlled would be specific to the methods in the
cardedge interface. So, for example, if one applet instance has root keys,
and another as verification keys, the two cooperate in the custom
application domain to provide a distributed object network that enforces
the security model: the instances may be executing on one card platform, or
several: the security services that GP applies on data flow between two
applet instances will thus depend on which security domain the instance is
controlled by, and whether the two instance may be connected by local IPC
(i.e. SIOs on the same platform) rather than serializing APDUs for bus
transfer between instanceds on different cards.

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

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