Hi Tim,
Awesome to hear from you, glad your back, hope everything's going well
for you now.
I'm after all ideas, what I'm thinking about is something Similar to
Mike Warres codebase service, with a twist:
1. During Marshalling of a Service, collect package names and
versions (Utilising the Java Package Versioning Spec, works for
OSGi too) and annotate the service proxy (requires a new URL
implementation).
2. The client checks if any local packages satisfy the package name
and version.
3. If not found locally, the client queries a codebase resolution
service with the package name, version and a list of public key
certificates (these might be common to both the client and the
service).
4. The codebase resolution service returns a message digest of a jar
file that satisfies the package name, version and signers (public
key certificates) if possible over a secure connection.
5. The client uses this hashcode digest to request the jar file from
a codebase service.
6. When the jar file arrives, the client checks the message digest,
followed by the signers.
7. Trust, (permission grants) is based on the identity of the signers
public key certificates.
Codebase annotation loss can be prevented by generating it from the
local package version during marshalled, ensuring local code also gets
an annotation.
What I'm wondering is, it would be neat if the Service could apply a
constraint on the signers of the jar file, perhaps the codebase
resolution service could be a mediator? The client takes the greatest
risk by using downloaded code, however it would be nice if there were
some way the Service could verify the code is signed by someone reputable.
I'm thinking about utilising an HMAC digest and utilising the bouncy
castle security provider.
Cheers,
Peter.
Tim Blackman wrote:
On Apr 29, 2010, at 3:23 PM, Gregg Wonderly wrote:
Peter Firmstone wrote:
I don't know how to enable the Service to specify a constraint on the signer of
the downloaded codebase if not originating from the service, any ideas?
The HTTPMD protocol handler (URLStreamHandler) does this by requiring that you
know the MD5 sum of the jar that you want to download. If you try and download
the jar, and the sum is different, you can know that the content is not what
you originally knew it to be.
Not directly signing, but a mechanism that is similar and provides a fairly secured
indication of "source" based on what you knew at the moment you acquired the
MD5 sum.
As long as you use a strong enough message digest -- SHA-1 or something still
stronger would be better choices these days now that the safety of MD5 is
uncertain -- the security of HTTPMD is just as good as that of code signing.
- Tim
