secure inter-module references

Jecel Assumpcao Jr jecel at merlintec.com
Wed Mar 2 14:22:25 UTC 2005


This is a bit off topic, but I thought it would be interesting to think
about what kinds of issues can come up when dealing with security.

For example, can you have unforgeable inter-module references if the
system is open source and any given node might be running a version with
arbitrary modifications? What if access to the actual bytes in a module
is relatively easy to obtain?

I think what follows is a correct solution to this problem, but not
something we would ever want to actually do given the high overhead.

First we somehow have a universal reference to the module itself, M.
Then we associate a sufficiently large random number, K, with a given
object within the module. An object in another module can refer to this
object with the pair

    Cap := { M. K }.

When we load M, it includes an object table (in-pointers table). We
generate a tag

    Tag := K oneWayFunction.

and then use K with a simple hash to index into the table looking for an
entry with Tag. Here there are many interesting variations that could be
done, but which don't really matter for this example.

    i := objTable probeFor: Tag startingAt: K simpleHash.

Once we have the correct entry, it will also give us the first byte
position and object length so we can fetch the content of the object.
That has been encrypted with K, so we reverse the process and we are
done.

    start := (objTable at: i) start.
    obj := (module from: start to: start + (objectTable at: i) length)
decryptWith: K.

So if you have the module itself you can see how many objects it has and
what their sizes are but without a valid Cap you won't be able to read
any of the objects. And you won't be able to guess K by looking inside
the module - someone else will have to give it to you. Once you are able
to read an object, of course, it might itself include remote references
and so you will have one or more valid Caps that you can use to get even
more objects.

A nice property of this scheme is that a remote reference is not
affected if we add or remove objects from M. But such details aren't
important - I am just trying to see in general what the solutions we
will need might look like.

-- Jecel



More information about the Modules mailing list