# Security Architecture in JDK 1.2 suggestion

Derrick L. Hatcher (derrick@fsts.com)
Thu, 11 Dec 1997 11:43:27 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Jose Ramon Huerga: "Activator & Signed JAR files"
- Previous message: Joseph Bowbeer: "signed applets article"
- Next in thread: Charlie.Lai@Eng: "Re: Applet Signing and Printing"

    Date: Thu, 11 Dec 1997 11:43:27 -0500

    From: "Derrick L. Hatcher" <derrick@fsts.com>

    To: java-security@web1.javasoft.com

    Subject: Security Architecture in JDK 1.2 suggestion

This is a multi-part message in MIME format.
--------------223EF113CEEAA6B74CA16FC1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have perused the architecture the last couple of days and still find
a concept missing that hinders its usability for our purposes.
Specifically, the notion of hardware-based cryptographic providers
(i.e. crypto cards) and their needs do not appear to be addressed.
More particularly, while the new keystore concept and opaque keys
allows for the possibility of implementing a crypto card provider,
the lack of any session management precludes implementing such
a provider in a standard way.

My suggestion is that a new interface be defined for the Provider
class: "SessionBased". If a provider implements the SessionBased
interface, then an application will know that the provider requires
a session open before any cryptographic operations will succeed.
The interface would be something like the following:

public interface SessionBased
{
public abstract Session openSession() throws InvalidSession;
public abstract closeSession(Session s) throws InvalidSession;
}

I would specifically not include any parameters in the openSession
call and rather let the Provider instantiate a UI object (dialog
box for the PIN, whatever) to authenticate the user. This keeps
the PIN or passphrase from being inadvertantly exposed by the client
application.

The Session parameter would then become an additional parameter
to the calls that instantiate algorithms (the MessageDigest.getInstance
method for instance). A closeSession call would of course invalidate
the algorithms provided by the session-based provider; a new openSession
and getInstance sequence would need to be performed.

I sincerely hope that this suggestion will be useful in your endeavors
and thank you for the opportunity to provide my input.

Derrick Hatcher
--------------223EF113CEEAA6B74CA16FC1
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Derrick Hatcher
Content-Disposition: attachment; filename="vcard.vcf"

begin: vcard
fn: Derrick Hatcher
n: Hatcher;Derrick
org: XCert International
adr: 681 Emory Valley Road;;;Oak Ridge;TN;37830;USA
email;internet: derrick@fsts.com
title: Systems Analyst
tel;work: (423) 481-0061
tel;fax: (423) 482-1727
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard

--------------223EF113CEEAA6B74CA16FC1--

- Next message: Jose Ramon Huerga: "Activator & Signed JAR files"
- Previous message: Joseph Bowbeer: "signed applets article"
- Next in thread: Charlie.Lai@Eng: "Re: Applet Signing and Printing"