3

In the process of decrypting an encrypted data, i am having a little challenge with it. I will be so glad if anyone can help putting me through.

Although, i have already studied the algorithm in carrying out this operation, since i am to get my data from a device, which already has its Base Derivation Key(BDK), Initially loaded key serial number and the initially loaded pin entry device key.

In the documentation that was been given, we have the Initially loaded key serial number, data encryption key variant and the track 2 Data (which is in plaintext).

In this example, i was made to know that they actually used a 3DES-128 bits CBC Mode (padding zero) method.

my question now is, how was the plaintext gotten from the encrypted data. I will be so glad, if anyone can put me through (stating the flow or the algorithm to use in decrypting this data).

Will so much appreciate your time.

  • 3DES is 168-bits. Sometimes part of the key is reused so it is 112-bits. The difference is because only the MS 7-bits per byte are used, the LS bit was initially used for parity but is generally ignored in current usage. But, DES and 3DES should not be used in new work, instead use AES which supersedes DES. If no padding is used the input data must **always** be a multiple of the block size, 8-bytes for DES, PKCS#5 padding is usually used. – zaph Sep 19 '16 at 18:05
  • Your test data suggest you are talking about DUKPT keys. This is quite an involving process .. I found much help in [this blog](https://www.parthenonsoftware.com/blog/how-to-decrypt-magnetic-stripe-scanner-data-with-dukpt/) when implementing it. – Ebbe M. Pedersen Sep 19 '16 at 18:15
  • 1
    @zaph but, in the process of its encryption, i was been made to know that, 3DES was actually been used for its encryption. Does it mean it is possible to use AES in decryption a 3Des encrypted data? –  Sep 19 '16 at 18:19
  • @EbbeM.Pedersen thanks so much for that pointer, I already tried using the flow too, but i haven't been getting it right. –  Sep 19 '16 at 18:21

2 Answers2

1

One of the more stupid things about the Oracle implementation is that the SecretKeyFactory does not support DES ABA keys, also known as "two-key" DES keys.

These keys for triple-DES operation consists of a single DES key A, followed by single DES key B. Key A is used both for the first and last iteration of DES within DES EDE (Encrypt-Decrypt-Encrypt).

If you stay within software you can create a method to create such keys. The problem is that the resulting keys actually have 192 bits, which is simply not correct - it makes it impossible to distinguish between the key sizes.

Anyway, the following code can be used to generate DES ABA keys:

private static final int DES_KEY_SIZE_BYTES = 64 / Byte.SIZE;
private static final int DES_ABA_KEY_SIZE_BYTES = 2 * DES_KEY_SIZE_BYTES;
private static final int DES_ABC_KEY_SIZE_BYTES = 3 * DES_KEY_SIZE_BYTES;

public static SecretKey createDES_ABAKey(byte[] key) {
    if (key.length != DES_ABA_KEY_SIZE_BYTES) {
        throw new IllegalArgumentException("128 bit key argument with size expected (including parity bits.)");
    }
    try {
        byte[] desABCKey = new byte[DES_ABC_KEY_SIZE_BYTES];
        System.arraycopy(key, 0, desABCKey, 0, DES_ABA_KEY_SIZE_BYTES);
        System.arraycopy(key, 0, desABCKey, DES_ABA_KEY_SIZE_BYTES, DES_KEY_SIZE_BYTES);
        SecretKeySpec spec = new SecretKeySpec(desABCKey, "DESede");
        SecretKeyFactory factory = SecretKeyFactory.getInstance("DESede");
        SecretKey desKey = factory.generateSecret(spec);
        return desKey;
    } catch (GeneralSecurityException e) {
        throw new RuntimeException("DES-EDE ABC key factory not functioning correctly", e);
    }
}

OK, so that leaves us with the CBC encryption (no padding, and zero IV):

private static final byte[] ENCRYPTION_KEY = Hex.decode("448D3F076D8304036A55A3D7E0055A78");
private static final byte[] PLAINTEXT = Hex.decode("1234567890ABCDEFFEDCBA0987654321");

public static void main(String[] args) throws Exception {
    SecretKey desABAKey = createDES_ABAKey(ENCRYPTION_KEY);
    Cipher desEDE = Cipher.getInstance("DESede/CBC/NoPadding");
    IvParameterSpec zeroIV = new IvParameterSpec(new byte[desEDE.getBlockSize()]);
    desEDE.init(Cipher.ENCRYPT_MODE, desABAKey, zeroIV);
    byte[] ciphertext = desEDE.doFinal(PLAINTEXT);
    System.out.println(Hex.toHexString(ciphertext));
}

I've used the Bouncy Castle hexadecimal codec, but other hexadecimal codecs can also be used.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • thanks so much for your explanation, and i would like to know the Bouncy Castle Hexadecimal codec you used, bcprov-jdk15-130.jar and also bcprov-1.45.jar but still not seeing the .toHexString method. thanks for your time once again. –  Sep 20 '16 at 09:37
  • and, how can i also decrypt and encrypted data which was been encrypted with a KSN and a BDK key?? –  Sep 20 '16 at 09:38
  • I'll chech the codec at home but that doesn't really matter. I don't know the protocol so I'm not sure how to handle the other keys. – Maarten Bodewes Sep 20 '16 at 10:02
1

Since you want to try to carrying out the 3DES-128 bits CBC Mode (padding zero) method, try out this git https://github.com/meshileya/dukpt to use in getting the plaintext from the ciphertext.

Since you already have your BDK and KSN, just try to run the method below.

 public static void main(String[] args) {
     try {
        String theksn = "This should be your KSN";
        String encrypted = "This should be the encrypted data";
        String BDK = "The BDK you mentioned up there";

            tracking= DukptDecrypt.decrypt(theksn, BDK, encrypted);

            System.out.print("PlainText"+ tracking);
        }catch (Exception e){System.out.print(e);}

    }
Israel Meshileya
  • 293
  • 4
  • 18