解密加密DUKPT跟蹤數據

正如標題所說，我試圖解密加密DUKPT軌跡數據從啓用DUKPT掃描器的。解密加密DUKPT跟蹤數據

我有DUKPT在ANSI標準（X9.24），並已成功實施從KSN和BDK產生伊佩克的能力。此外，我已成功實現了通過對PIN加密密鑰進行異或來生成左右MAC請求和響應密鑰的功能。最後，我能夠生成EPB。

從這裏，我不明白如何從我所產生的L/R鍵的MAC請求和響應。

最後，一旦我走到那一步，接下來會發生什麼？我什麼時候能夠解密由啓用DUKPT的設備發送的軌道數據的密鑰？

我意識到泰雷茲模擬器和jPOS。我的代碼目前正在引用泰利斯模擬器來完成所有工作。但是，文件解密過程並沒有返回預期的數據。

如果有人可以提供一些洞察到解密的軌道數據，這將是大加讚賞。

http://thalessim.codeplex.com/

http://jpos.org/

來源

2012-07-31 bdeetz

我花了太多時間研究可怕X9.24規格，終於得到了加密和解密與我的供應商的實例和營銷工作及時決定交換機廠商。既然它是一個標準，你會認爲任何人的實現都是一樣的。我希望。無論如何，有關如何實施的變化。你必須研究細則以確保你的工作與你的另一面相同。

但這不是你的問題。

首先，如果你需要從信用卡解密數據軌道，你可能有興趣生產，這將解密仍按原超級祕密基地推導關鍵數據的關鍵。這與MAC一代沒有任何關係，只是在傳遞這個可怕的規範時才提到。您需要爲該密鑰序列號和設備ID生成IPEK，並且如果在HSM的完整密鑰序列號的計數器部分中設置了位，則重複應用規範中的「不可逆密鑰生成過程」。

那我的代碼部分如下：（對不起，在張貼的長列表。）

/* 
* Bit "zero" set (this is a 21 bit register)(ANSI counts from the left) 
* This will be used to test each bit of the encryption counter 
* to decide when to find another key. 
*/ 
testBit=0x00100000; 
/* 
* We have to "encrypt" the IPEK repeatedly to find the current key 
* (See Section A.3). Each time we encrypt (generate a new key), 
* we need to use the all prior bits to the left of the current bit. 
* The Spec says we will have a maximum of ten bits set at any time 
* so we should not have to generate more than ten keys to find the 
* current encryption key. 
*/ 
cumBits=0; 
/* 
* For each of the 21 possible key bits, 
* if it is set, we need to OR that bit into the cumulative bit 
* variable and set that as the KSN count and "encrypt" again. 
* The encryption we are using the goofy ANSI Key Generation 
* subroutine from page 50. 
*/ 
for(int ii=0; ii<21; ii++) 
{ 
    if((keyNumber&testBit) != 0) 
    { 
     char ksr[10]; 
     char eightByte[8]={0}; 

     cumBits |= testBit; 
     ksn.count=cumBits; /* all bits processed to date */ 

     memcpy(ksr, &ksn,10);  /* copy bit structure to char array*/ 
     memcpy(crypt,&ksr[2],8); /* copy bytes 2 through 9 */ 

     /* 
     * Generate the new Key overwriting the old. 
     * This will apply the "Non-reversible Key Generation Process" 
     * to the lower 64 bits of the KSN. 
     */ 
     keyGen(&key, &crypt, &key); 
    } 
    testBit>>=1; 
}

哪裏 keyNumber從KSN KSN當前計數器是一個80位的結構，其中包含HSM crypt的80位密鑰序列號是一個64位的數據塊，因爲我使用的是openSSL，所以它有DES_cblock類型。密鑰是一個128位雙DES_cblock結構。 keyGen例程幾乎完全來自規範第50頁上的「不可逆密鑰生成過程」本地子例程。

在這段結束時，關鍵變量將包含可用於解密的密鑰，幾乎。編寫規範的帥哥在關鍵時加入了一些「變體」行爲，讓我們留在腳趾上。如果密鑰要用於解密諸如信用卡軌道之類的數據流，則需要使用0xFF對字節5和13進行XOR，並使用Triple DES對其自身（ECB模式）進行加密。我的代碼如下所示：

DOUBLE_KEY keyCopy; 
char *p; 
p=(char*)&key; 
p[ 5]^=0xff; 
p[13]^=0xff; 
keyCopy=key; 
des3(&keyCopy, (DES_cblock *)&key.left, &key.left); 
des3(&keyCopy, (DES_cblock *)&key.right, &key.right);

如果您正在使用此解密PIN塊，你需要XOR字節7和15爲0xFF。（我不是100％肯定這不應該適用於流模式，但我的供應商將它放棄。）

如果它是PIN塊，它將在ECB模式下使用3-DES進行加密。如果它是一個數據流，它將在CBC模式下以零初始化向量加密。

（難道我提到我對規格不太在意？）有趣的是，如果服務器端（上面）記住並且加密端可以用於非硬件防篡改安全模塊拒絕先前使用的密鑰。技術非常整齊。 ANSI規範留下了一些需要的東西，但技術是可以的。

祝你好運。 /鮑勃·布萊恩

來源

2012-08-03 23:17:42

也就是說一些精彩的信息相關的代碼。感謝您抽出寶貴時間回覆這些細節。我一定會繼續提供你所提供的工作。 – bdeetz 2012-08-06 14:15:10

我希望我能給你一票。互聯網上最好的資源。 – Jonathan 2013-02-07 23:50:39

對於數據加密，所述變體是0000000000FF0000.0000000000FF0000所以需要XOR字節5和13代替圖7和15中。另外，需要每個關鍵部位的附加3DES自加密步驟（左和對）。

這裏是初級專業人員 https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/security/jceadapter/JCESecurityModule.java#L1843-1856

來源

2013-04-23 21:28:13 apr

解密加密DUKPT跟蹤數據

回答

相關問題