----- Original Message ----- From: "Tommaso Cucinotta" <[EMAIL PROTECTED]>
To: "MUSCLE" <[EMAIL PROTECTED]>
Sent: Monday, November 15, 2004 2:39 AM
Subject: Re: [Muscle] executing an "APDU script" stored in a muscle object
as other things, in the software area everything is possible, especially when it is open-source. If we cannot feed the stored APDUs in the JCE buffers, we can surely provide them in an another buffer, and change the code so to use a provided buffer, instead of getBuffer(). This does not really matters.
Its the JCE route I was thinking of using : so that the card & transaction state continues to be managed. Im imagining that transaction rollback, anti-tearing mode etc tend will have buffers that assume single-element transactions.
What really matters is: how would you use such functionality ? What would it be worth for ? Could you provide an example of how such functionality would help in doing something in a somehow more meaningful way than you would do with the protocol as it is right now ?
Beyond the state machines provided by javacard and global platform, for higher assurance design work I need to impose my own state machine - treating the cardedge as a state-based TLV *communication* object - rather than as an API to the various javacard libraries, which handled TLV-encoded *data* objects.
e.g. certain . objects are unlocked as a group, only when id X is logged in
e.g. login by X causes card to verify signatures on all elements in that group
e.g. parse the signature-verified TLV object into its components, reprsenting the primitive objects as native javacard types.
e.g. state and method results are stored in the output/audit object
The idea is that the IN object (or any identified object, really) becomes a simple stored procedure, basically.
Then, I guess you would like to store the APDU results into the output object, in some format.... :-)
That had occured to me!
I did wonder if I was overworking this idea, however. As each cardedge method is only a proxy for an APDU whose INS is decoded by process(), the stored procedure in an object could just aswell be a script of compiled java opcodes, rather than then the sequence of APDUs. But then, we are going to run into the reference monitor guards in the VM. Will it allow arbitrary opcodes stored in object to be executed in the security context of the method responding to the original APDU? In C on UNIX, we can all deference a function pointer to an abitrary block of memory. Can we do that in javacard security model, however, is the question.
The other way to go is to go is to export an SIO interface pointer to the cardedge to another applet, which can then drive the higher-layer logic. The programming is then at least consistent with what the designers of the "inter-process" security model were anticipating.
I may have to break down, and start reading the JCE source, to find out what the model does in reality, determining which de-referencing functions are software enforced, and which are delegated to the bus/memory manager on the chip.
Bye,
T.
_______________________________________________ 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
