Security services deployer for the MC

[dmlloyd]

I've made another deployer. The purpose of this deployer is to support the injection of security-related entities (Ciphers, SecureRandoms, MessageDigests etc).

It lives in the sandbox here: http://anonsvn.jboss.org/repos/sandbox/david.lloyd/jboss-securityservice/trunk

To use it in a deployment, you'd do something like this (example taken from the XNIO SSH implementation in development):

 <security-service xmlns="urn:jboss:security-service:1.0">

 <!-- standard Diffie-Hellman key exchangers -->

 <secure-random name="SshSecureRandom" algorithm="SHA1PRNG"/>

 <diffie-hellman-parameter-spec name="OakleyGroup2">
 <generator value="2"/>
 <prime radix="16">
 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
 FFFFFFFF FFFFFFFF
 </prime>
 </diffie-hellman-parameter-spec>

 <diffie-hellman-parameter-spec name="OakleyGroup14">
 <generator value="2"/>
 <prime radix="16">
 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
 E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
 </prime>
 </diffie-hellman-parameter-spec>

 <key-factory kind="factory" name="DHKeyFactory" algorithm="DiffieHellman"/>

 <key-agreement kind="factory" name="DHKeyAgreement" algorithm="DiffieHellman"/>

 <key-pair-generator kind="factory" name="DHKeyPairGenerator" algorithm="DiffieHellman"/>

 <message-digest kind="factory" name="DHSHA1Digest" algorithm="SHA-1"/>

 <!-- SSH MAC algorithms -->

 <mac kind="factory" name="SshMac-hmac-sha1" algorithm="HmacSHA1"/>

 <mac kind="factory" name="SshMac-hmac-sha1-96" algorithm="HmacSHA1" truncate-length="96"/>

 <mac kind="factory" name="SshMac-hmac-md5" algorithm="HmacMD5"/>

 <mac kind="factory" name="SshMac-hmac-md5-96" algorithm="HmacMD5" truncate-length="96"/>

 <!-- SSH Ciphers -->

 <cipher kind="factory" name="SshCipher-DESede" algorithm="DESede/CBC/NoPadding"/>
 <cipher kind="factory" name="SshCipber-Blowfish" algorithm="Blowfish/CBC/NoPadding"/>
 <cipher kind="factory" name="SshCipher-AES" algorithm="AES/CBC/NoPadding"/>
 <cipher kind="factory" name="SshCipher-ARC4" algorithm="ARCFOUR/ECB/NoPadding"/>
 <!-- SSH public key algorithms -->

 <cipher kind="factory" name="SshCipher-rsa" algorithm="RSA"/>

 </security-service>

Then these things are available for injection as standard POJOs, which decouples the data (like the large primes) and the configuration (the ciphers etc.) from the application.

I can't really think of any way to justify sticking this in to the MC proper, but if anyone has any interest in any of this functionality, I'll be putting out a real release sometime before the XNIO SSH implementation is released...

[anil.saldhana]

JaasSecurityDomain - the MBean (which can also be used as a POJO) has been the level of sophistication that we have required from security use cases.

[dmlloyd]

This module in no way has any overlap with any authentication or authorization system. It is merely a way to declare objects defined in java.security and javax.crypto as POJOs which can be injected, to allow configuration and data to be separated from logic; a class IoC use case in my opinion.

[starksm64]

The usecase for having something like this in an mc subproject would be adding support for hashed and encrypted property values in the xml descriptors. Right now the jca mbeans have support for this, but it should be a generic facility.

The jca mbeans rely on communicating with a JaasSecurityDomain. This should be generalized into a security aspect.

[dmlloyd]

The classic problem with encrypting values is that somewhere - somehow - you have to store or acquire the secret/private key or password so that the server can decrypt the value. For a server starting up, it's hard to imagine a place that a key/password could be stored that would be more secure than where its regular configuration could be stored.

While this module would definitely make it easer, in some ways, to get the tools needed to perform the encryption/decryption, it does nothing to solve this basic problem.

[starksm64]

You would need a password source bean to inject this from a configured source. The basic problem has no general solution, so you have to allow the users to configure how its bootstrapped. I don't see this as an impediment to working towards a general encryption capability.

[dmlloyd]

Sure, I was just following the line of thought. A generalized password storage/injection mechanism is an interesting idea, similar in requirements to storing keys really. Anyway I'll have to have some solution to this problem to finish the SSH implementation...

[anil.saldhana]

Sure, I was just following the line of thought. A generalized password storage/injection mechanism is an interesting idea, similar in requirements to storing keys really. Anyway I'll have to have some solution to this problem to finish the SSH implementation...

One possible solution is to centralize the keys in a key server that can be accessed by both the client and the server. They need to communicate to the key server via strong pki. JBoss XMLKey (as part of JBoss Identity) is the direction for this (preliminary but slow steady strides).

[dmlloyd]

But then, of course, the client servers need a password or key to access the central key server, which then brings you back to the original problem...

[anil.saldhana]

But then, of course, the client servers need a password or key to access the central key server, which then brings you back to the original problem...

Of course, it boils down to safeguarding private keys. I have not looked at solutions here (TPM, HSM etc). :)

I was wondering why there was a need to inject DH Key Agreement internals as POJO, then seeing that you are planning to do SSH implementation - it made sense. One other area, where it makes sense is the implementation of WS-SX (Web Service Secure Conversation).

[dmlloyd]

I'm in the process now of adding tags to create injectable keys from key files and keystores. A logical extension of that would be to inject passwords (read from files? maybe as char arrays, maybe as some kind of opaque object (like a CallbackHandler that handles PasswordCallbacks perhaps?)). What kind of security precautions should be taken? The implication here is that if the password "lives" in the microcontainer's managed space, then anyone who has access to that space gets the password. Maybe a special permission that includes the password bean name should be required to access it? What do you guys think? If I introduce special permissions for password access, I would think we'd want to do the same for SecretKey/PrivateKeys as well since they have similar security implications from what I can see.

[anil.saldhana]

I'm in the process now of adding tags to create injectable keys from key files and keystores. A logical extension of that would be to inject passwords (read from files? maybe as char arrays, maybe as some kind of opaque object (like a CallbackHandler that handles PasswordCallbacks perhaps?)). What kind of security precautions should be taken? The implication here is that if the password "lives" in the microcontainer's managed space, then anyone who has access to that space gets the password. Maybe a special permission that includes the password bean name should be required to access it? What do you guys think? If I introduce special permissions for password access, I would think we'd want to do the same for SecretKey/PrivateKeys as well since they have similar security implications from what I can see.

* Apart from directly injecting passwords from files, another option would be to use Password Based Encryption (password, salt, iteration count).
* Agree on the special permission. I feel that a special permission category (similar to classloader perm) can be created to give a super user type access to the sensitive keys and then individual permissions for the password, privatekey....

[dmlloyd]

I'm going to change the name of this to "cryptography services" to avoid confusion with any other security-related projects.

[anil.saldhana]

I'm going to change the name of this to "cryptography services" to avoid confusion with any other security-related projects.

DML, it is mainly config used by the JDK crypto stuff. Right? I am unsure if you plan to provide any crypto implementation. If the former, then the name can be misleading. If the latter, we should discuss.

[dmlloyd]

At the moment there's provisions for deploying other JCA providers (like BouncyCastle) though I'm not sure I can/should keep that (the JDK has its own provider deployment mechanism and there isn't a great way to make them play together that I can see). As for providing alternate implementations, I do not have any plans to do so at this time, though these services can work with any provider implementation.

I chose the name because all these provided services relate specifically to cryptography, so it seems to make sense to me.