[Muscle] .Net remoting channel, muscle://

[Peter Williams]

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
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle