Recreating IDM 3Des encryption in Java via extension Framework

[former_member586836]

In our IDM implementation we need to store a secondary password which we're using in a two factor authentication process. Recreating the storage of this password in IDM is easy, but to due to compliance reasons we must ensure the secondary password does not match the existing regular password in IDM.

I'm using the extension framework to add the online Java logic in the portal, if a password doesn't match our complexity rules or matches the existing MX_ENCRYPTED_PASSWORD then the user gets a message when they attempt to save. However, I'm running into an issue, the usual Java crypto functions that create 3Des encryption are returning a different password than the uDesEncrypt function inside IDM when using an identical key.

Has anyone experienced this before, does anyone know the correct way in which to call the Java cipher object so that I get an identical result to the uDesEncrypt function?

Thanks,

Pete.

[Former Member · Accepted solution]

Are you sure that your using the exact same key for the encryption?

The key should be in the file <installation directory>\key\keys.ini

But another thing there is to notice is that the key in keys.ini is longer than 24-chars (at least in my case) which the doc for uDesEncrypt says it must be (in the Java case) so maybe this could give some problems.

[former_member586836 · Accepted solution]

Yes, sure it's the key IDM is using. I've tried several options when passing it to the Java object such as sending it as is, reducing its length to match the uDesEncrypt doc, I've also tried converting it from a hex string to a decimal, and prefixing with . I'd be happy if someone could tell me how to format the key to get the correct result but so far all the variations I've tried fail.

[former_member586836 · Accepted solution]

Something I've noticed in case that jogs any thoughts...the SAP documentation says

the result is prefixed by followed by the key number used when encryption. Then the encrypted data is stored as base64. However when I look at the data it doesn't look like base64, it doesn't end with an = for example? Here's an example of the data I see in IDM 1:F700AD168253BC248497969EDB988620

Does anyone know if that doc statement is accurate?

Edited by: Pete Simms on Feb 29, 2012 10:47 PM

[Former Member · Accepted solution]

Well, it's inaccurate -- it's just hex-encoded. The relevant hex-encoded part is the F700AD168253BC248497969EDB988620 -- the 1: means it was encrypted by KEY001 in keys.ini. I am able to generate the same encrypted string using both uDESEncrypt and the javax.crypto classes, algorithm = "DESede", transformation = "DESede/CBC/PKCD5Padding". I get the result "1:0653565108cc220e" from uDESEncrypt and "0653565108CC220E" from the java.

My suggestion to you would be to change the keys.ini KEY00x that you think is being used, verify that generated DES3 within IDM changes, then use that hex key with a quick function using javax.crypto to ensure that you're using the same generation method and keys. Some sample java code that should produce the same results as uDESEncrypt (without the "1:" bit) is below.

String PLAIN_TEXT = "YOUR TEXT HERE";

String SHARED_KEY = "YOUR KEY HERE"; // just the 48 hex characters

String algorithm = "DESede";

String transformation = "DESede/CBC/PKCS5Padding";

byte[] keyValue = Hex.decodeHex(SHARED_KEY.toCharArray());

DESedeKeySpec keySpec = new DESedeKeySpec(keyValue);

IvParameterSpec iv = new IvParameterSpec(new byte[8]);

SecretKey key = SecretKeyFactory.getInstance(algorithm).generateSecret(keySpec);

Cipher encrypter = Cipher.getInstance(transformation);

encrypter.init(Cipher.ENCRYPT_MODE, key, iv);

byte[] input = PLAIN_TEXT.getBytes("UTF-8");

byte[] encrypted = encrypter.doFinal(input);

System.out.println(new String(Hex.encodeHex(encrypted)).toUpperCase());

Edited by: Chris Foley on Mar 1, 2012 2:01 AM

[former_member586836 · Accepted solution]

Thanks Chris! Works like a charm.

Cheers, Pete.