Data Migration !
dinhc...@gmail.com
Firstly , Our questions is about Data migration with Pin block but i
believe members have experience shall help me and give me ideas.
My bank have new Switch system and no longer to use Switch from other
bank that is used in the past . Problem is that old information
includes card , cvv , expired date and pin is stored on that bank
because this bank issue card instead of my bank
So we need to migrate pin decrypted under their LMK to my LMK .
This is my step i am thinking , would anybody give advise :
- We set HSM support clear pin
- Export Pin block from another bank .
- Decrypt an Encrypted PIN ( using command message : NG)
- Encrypt new clear pin ( using command message : LH)
and stored this new value
Thanks so much .
ochomo
I think it will be safe to just migrate the card data and regenerate
PIN and reprint PIN Mailers.
Which means your bank incurs some expense of PIN Mailer printing and
delivering to customer.
Option 2.
Migrate all card information and find out from the HSM supplier on how
to use your new LMK with information encrypted under former HSM's LMK.
Option 3.
Using NG command to get the clear PIN is very bad way of working. My
advice is not to do that.
I am sure there is a way of achieving that but you need to talk to HSM
supplier.
On Jun 16, 7:55 am, "dinhchun...@gmail.com" <dinhchun...@gmail.com>
wrote:
Mark Salter
> Hi all ,
> Firstly , Our questions is about Data migration with Pin block but i
> believe members have experience shall help me and give me ideas.
> My bank have new Switch system and no longer to use Switch from other
> bank that is used in the past . Problem is that old information
> includes card , cvv , expired date and pin is stored on that bank
> because this bank issue card instead of my bank
> So we need to migrate pin decrypted under their LMK to my LMK .
> This is my step i am thinking , would anybody give advise :
> - We set HSM support clear pin
Which HSM do you use?
> - Export Pin block from another bank .
I'm assuming that the source bank will not be sharing their LMK with
you, so perhaps these will be encrypted under a new key specifically for
this export?
> - Decrypt an Encrypted PIN ( using command message : NG)
> - Encrypt new clear pin ( using command message : LH)
Rather then decrypt+encrypt, does your HSM provide a translate command?
Combining these two functions into one so that the PIN is never in the
clear *outside* of the HSM?
> and stored this new value
I wonder if you are talking about PIN Blocks in transactions - rather
than PINs themselves?
--
Mark
Chung vu
Thanks for reply , below is my answer
Chug
Option 1.
I think it will be safe to just migrate the card data and regenerate
PIN and reprint PIN Mailers.
Which means your bank incurs some expense of PIN Mailer printing and
delivering to customer.
If it is good solution if we have a lot of ATM , we want to customer change PIN after receiving new card. But our ATM is limit . Fraund happens if they don't change pin due to their have money.
Option 2.
Migrate all card information and find out from the HSM supplier on how
to use your new LMK with information encrypted under former HSM's LMK.
Would you have experience with this solution or we export pin dunder ZMK and load change encrytion from ZMK to our LMK , i see HSM commands guide . Is it okie ?
Chung vu
My answer is below
Do you really store the PIN in an encrypted form?
dinhc...@gmail.com wrote:
> Hi all ,
> Firstly , Our questions is about Data migration with Pin block but i
> believe members have experience shall help me and give me ideas.
> My bank have new Switch system and no longer to use Switch from other
> bank that is used in the past . Problem is that old information
> includes card , cvv , expired date and pin is stored on that bank
> because this bank issue card instead of my bank
> So we need to migrate pin decrypted under their LMK to my LMK .
Which HSM do you use?
> This is my step i am thinking , would anybody give advise :
> - We set HSM support clear pin
I'm assuming that the source bank will not be sharing their LMK with
> - Export Pin block from another bank .
you, so perhaps these will be encrypted under a new key specifically for
this export?
Rather then decrypt+encrypt, does your HSM provide a translate command?
> - Decrypt an Encrypted PIN ( using command message : NG)
> - Encrypt new clear pin ( using command message : LH)
Combining these two functions into one so that the PIN is never in the
clear *outside* of the HSM?
I wonder if you are talking about PIN Blocks in transactions - rather
> and stored this new value
than PINs themselves?
yes , i think about pin block . I think i have misunderstanding .
Would you make it clear ?
--
Mark
Mark Salter
>> Do you really store the PIN in an encrypted form?
>
> yes , i do . I see my vendor use Compare method to check pin .
The PIN verification - comparing the transaction PIN block (cardholder
entered PIN) with known value takes place inside the HSM via a command
to the HSM though?
Which command will you use - only asking out of interest...
.. what data components go into the this command?
>> Which HSM do you use?
>
> We use Thales 8000
Ok.
>
>>
>>> - Export Pin block from another bank .
>> I'm assuming that the source bank will not be sharing their LMK with
>> you, so perhaps these will be encrypted under a new key specifically for
>> this export?
>
> Can we do this ? Do you have experience or example ?
I would think so, I have never done this myself...
Assuming the source bank is not going to give you their LMK, they can
generate a key and share it with you securely - do you have a
documented/known key exchange process with them?
They can then translate the PIN from under their LMK to be under this
this new transport key and send you the file - probably also encrypted
under another set of keys and algorythm.
You can then translate the PIN from under the transport key to be under
your LMK in your HSM.
Those are the basic steps, each has work and perhaps discovery for you
to complete.
>
>>
>>> - Decrypt an Encrypted PIN ( using command message : NG)
>>> - Encrypt new clear pin ( using command message : LH)
>> Rather then decrypt+encrypt, does your HSM provide a translate command?
>> Combining these two functions into one so that the PIN is never in the
>> clear *outside* of the HSM?
>>
>>> and stored this new value
>> I wonder if you are talking about PIN Blocks in transactions - rather
>> than PINs themselves?
>
>
> yes , i think about pin block . I think i have misunderstanding .
> Would you make it clear ?
PIN Blocks travel within a transaction that was acquired at a PIN based
device most usually an ATM - perhaps in field 52?
The ATM produces a PIN block using an acquirer working key which is
shared with the Switch, the Switch would then translate this PIN block
from under the AWK to be under a key the Issuer system knows so that the
Issuer can check (with an HSM) that the cardholder entered the correct PIN.
The HSM command would take the PIN block, the IWK (encrypted under LMK),
the card digits and the PIN key (again encrypted under LMK), other data
may also go in. The HSM then has enough data to be able to decide if
the PIN is correct.
If your system saves the actual PIN (encrypted) then that is different
to my experience.
Once this Switch is out of the flow, will you be dealing with the ATM's
directly?
In your opening question, perhaps when you use the word 'Switch' you
really mean 'Issuer system'?
--
Mark
Aissa.Slimani
1- You should first start a ZMK exchange process with the other Bank.
2- Generate a ZPK and transfer it encrypted under ZMK to the bank.
3- Ask the other bank to translate all Pin block from LMK to ZPK using JG
command
4- On your side translate the received pins under ZMK to your LMK using JE
command.
5- Get the CVKs under ZMK from the bank for CVV verifications
6- Translate and Load the CVK under LMK in your system using AW command
7- test and give me a call.
Aissa SLIMANI
Cap Payment Systems
www.cap-worldwide.com
-----Message d'origine-----
De : jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] De la
part de Mark Salter
Envoyé : mardi 16 juin 2009 08:42
À : jpos-...@googlegroups.com
Objet : Re: Data Migration !
Gustavo Núñez
Well, I Actually did that operation last year for a local bank that re-issued
all the customers cards due to a sponsor change (yes ... banks do such
things).-
The bank didn't want the customers to notice that change in the daily
operation, so they wanted to keep old pins with new cards. That requires a
new pin offset for each new card (It's not exactly the same case, but you
need to perform the same operations).
You may do this only if the pin validation that you use allowes it, there are
several pin validation methods that do not allow translation.
In my case, the bank used IBM 3624 pin validation method, that's an old DES
based validation method, so pin translation could take place.-
There are two ways of doing this. The right one and the one I chose. :-D
In every case you NEED BOTH criptograhic parameters, the one used for
generation the old pins and the ones you will use for the new ones.
I don't know about HSM commands, that's what manuals are for, but conceptually
you are doing a key translation, and that's what you must look for in your
manual, that's the proper procedure.-
The procedure I had to use (due to auditing restrictions) was to use a stand
alone machne with no HSM attached. I had to program to do that translation (I
loved it !).
I installed a postgres database on a linux box, programmed my own IBM 3624
encrypting/decrypting method, asked the bank to enter both, old and new
criptographic parameters, and I had a relation between old and new cards,
then voila ! in minutes they had the new pin offsets.
(In your case you wont't have a new PAN, just new keys)
Anyway, try to avoid decryption/encryption if you can. Encryption/encryption
operation take place in your HSM, but if you have 2 operations you may
expose intermediate results and that is not a good way to proceed.
This is one of the reasons why when you have to change crypto paramaters you
should use always translation (which is no more than encription/decription
but takes place all INSIDE your hsm as an atomic operation). When using
Translation in the proper way, you don't expose any security parameter
(decimalisation tables, offsets you use, keys, etc.)
I hope my experience helps you.
Regards.
Gus
Alejandro Revilla
> There are two ways of doing this. The right one and the one I choose. :-D
>
I believe your method is quite good if you do it in an isolated and
fully audited environment, and then you burn the machine and apply
electro shock to everyone involved in order to wipe their brains, but I
notice that this is not the case, you still remember ...
so it's probably time to change my PIN, just in case :)
Hey Gustavo, nice to see you around!
Chung vu
Below is my answer !
Thanks a lot for your comment.
The PIN verification - comparing the transaction PIN block (cardholder
Chung vu wrote:
>> Do you really store the PIN in an encrypted form?
>
> yes , i do . I see my vendor use Compare method to check pin .
entered PIN) with known value takes place inside the HSM via a command
to the HSM though?
Which command will you use - only asking out of interest...
.. what data components go into the this command?
To verify pin , we use messge BC ( COMPARISON Method) to compare pin block .
Pin block stored on DB is encryted under LMK .
data component for BC command:
The TPK under which the PIN block is encrypted; encrypted under LMK pair 14-15.
The PIN from the Host database encrypted under LMK pair 02-03.
The PIN block containing the PIN for verification; encrypted under the TPK
Is it clear ?
It is the same way you explain below . I think so .
Ok.
>> Which HSM do you use?
>
> We use Thales 8000
I would think so, I have never done this myself...
>
>>
>>> - Export Pin block from another bank .
>> I'm assuming that the source bank will not be sharing their LMK with
>> you, so perhaps these will be encrypted under a new key specifically for
>> this export?
>
> Can we do this ? Do you have experience or example ?
Assuming the source bank is not going to give you their LMK, they can
generate a key and share it with you securely - do you have a
documented/known key exchange process with them?
Would you have link or document to share for me ?
They can then translate the PIN from under their LMK to be under this
this new transport key and send you the file - probably also encrypted
under another set of keys and algorythm.
I already though about sólution
--
Mark
Chung vu
i check HSM manual , I think your solution is okie .
anything should be checked with initial security config (i am concerned with CS command)
Thanks once more time
Chung vu
My question is below , help me
Well, I Actually did that operation last year for a local bank that re-issued
all the customers cards due to a sponsor change (yes ... banks do such
things).-
The bank didn't want the customers to notice that change in the daily
operation, so they wanted to keep old pins with new cards. That requires a
new pin offset for each new card (It's not exactly the same case, but you
need to perform the same operations).
pin offset , what do you explian in detail , if we keep pin and change card number .
It is better solution for our customer .
You may do this only if the pin validation that you use allowes it, there are
several pin validation methods that do not allow translation.
In my case, the bank used IBM 3624 pin validation method, that's an old DES
based validation method, so pin translation could take place.-
can we do transatlte if pin validation method is Comparation method ?
Mark Salter
>> Which command will you use - only asking out of interest...
>>
>> .. what data components go into the this command?
>
>
> To verify pin , we use messge BC ( COMPARISON Method) to compare pin block .
> Pin block stored on DB is encryted under LMK .
> data component for BC command:
> The TPK under which the PIN block is encrypted; encrypted under LMK pair
> 14-15.
> The PIN from the Host database encrypted under LMK pair 02-03.
> The PIN block containing the PIN for verification; encrypted under the TPK
> Is it clear ?
Yes, that is fine.
> It is the same way you explain below . I think so .
It is similar, below I am describing PIN translation for the means of
transport.
Here your HSM is comparing two clear values (a clear PIN block - I would
guess).
> Would you have link or document to share for me ?
>
No, sorry I don't.
>>
>> They can then translate the PIN from under their LMK to be under this
>> this new transport key and send you the file - probably also encrypted
>> under another set of keys and algorythm.
>
>
> I already though about sólution
Ok, it is important to keep *all* card data secure.
--
Mark
Mark Salter
>>
>> The bank didn't want the customers to notice that change in the daily
>> operation, so they wanted to keep old pins with new cards. That requires a
>> new pin offset for each new card (It's not exactly the same case, but you
>> need to perform the same operations).
>
>
> pin offset , what do you explian in detail , if we keep pin and change card
> number .
The natural PIN is the one that is produced from the PIN generation
algorithm using the PIN generation key.
A PIN offset for a card with a natural 4 digit PIN would be 0000.
> It is better solution for our customer .
It might be better for you, but not for the cardholder - they don't care
as long as you take care.
>>
>> You may do this only if the pin validation that you use allowes it, there
>> are
>> several pin validation methods that do not allow translation.
>>
>> In my case, the bank used IBM 3624 pin validation method, that's an old DES
>> based validation method, so pin translation could take place.-
>
>
> can we do transatlte if pin validation method is Comparation method ?
Translate is something you do *between* two keys.
Your method means the HSM must get two clear values and return a value
indicating if they match.
The two things are therefore not really related.
--
Mark
gustavo...@adinet.com.uy
Check your HSM documentation to see if your pin verification method is
one of these:
? Atalla Identikey
? IBM 3624
? Visa PVV (PIN Verification Value)
? Atalla Bi-Level DES
? Diebold
? NCR
- Other.-
In the first case I think there's no solution (I'm not sure about
Diebold's verification process)
As Alejandro pointed early this ONLY works in an audited environment.
In fact the discs were destroyed after that operation (I think I heard
the auditors saying something about killing the programmer but I
managed to run away....) :-D
Mark also points that your "best solution" might not be the the
cardholder's best solution, as they don't care as long as you take
care. That's absolutely true, al sensitive data must be protected all
the time.
An ideal solution might include disabling for a while the pin change
function, in order not to allow data changes during migration,
So, please, tell us:
a) Algorithm name (I don't know the "comparison" method, please verify
that).
b) Availability of cryptographic parameters (old and eventually new).
c) Availability of testing environment (ATM, testing network, HSM,
etc)
d) The cost of programming inside your switch (do you have to do all
this stuff in TAL ???)
You should consider the cost of re-issuing cards. This could be the
cleanest solution.
Finally,
Regards.
Gus
----------------------------------------------------------------------------------------------
Hi Gusta ,
My question is below , help me
On Tue, Jun 16, 2009 at 8:10 PM, Gustavo Núñez <gustavo.nuniez@adinet.
com.uy
> wrote:
>
>
> Well, I Actually did that operation last year for a local bank that
> re-issued
> all the customers cards due to a sponsor change (yes ... banks do
such
> things).-
>
> The bank didn't want the customers to notice that change in the
daily
> operation, so they wanted to keep old pins with new cards. That
requires a
> new pin offset for each new card (It's not exactly the same case,
but you
> need to perform the same operations).
pin offset , what do you explian in detail , if we keep pin and
change card
number .
It is better solution for our customer .
>
>
> You may do this only if the pin validation that you use allowes it,
there
> are
> several pin validation methods that do not allow translation.
>
> In my case, the bank used IBM 3624 pin validation method, that's an
old DES
> based validation method, so pin translation could take place.-
can we do transatlte if pin validation method is Comparation method ?
>
Aissa.Slimani
Chung,
Nothing to be changed within the security config, as all used command does not involve clear pin operations. The HSM should of course be in the Authorized state.
The process is 100% safe if the 1st step (ZMK exchange) is secured by 3 allowed persons/components both from your side and the other bank side.
A i s s a.
De :
jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] De la part de Chung vu
Envoyé : mardi 16 juin 2009
17:17
Chung vu
With CVK , we use KA command to generage CVK A and CVKB . Both of key to generating .
With the ZMK single length , i can export this key.
But cvka and cvkb , to keep it securely , i use double length with algorithms in the past:
CVK2=CVKA+СVKB
I have a problem to export this CVK2 now .
Would you have any idea ?
Thanks
Chung
vu dinh chung
In the past , i don't know how to generate double length for CVK and PVK and i fowlow this rule when we have single :
3DES PVK=PVK1+PVK2
3DES CVK1=3DES
CVK2=CVKA+СVKB.
Aissa.Slimani wrote:
Chung,
Nothing to be changed within the security config, as all used command does not involve clear pin operations. The HSM should of course be in the Authorized state.
The process is 100% safe if the 1st step (ZMK exchange) is secured by 3 allowed persons/components both from your side and the other bank side.
A i s s a.
De : jpos-...@googlegroups.com [mailto: jpos-...@googlegroups.com ] De la part de Chung vu
vu dinh chung
Below is my answer .
b) Availability of cryptographic parameters (old and eventually new).
c) Availability of testing environment (ATM, testing network, HSM, etc)
HSM : Thales 8000
d) The cost of programming inside your switch (do you have to do all this stuff in TAL ???)
You should consider the cost of re-issuing cards. This could be the cleanest solution.
(Balance acccount is positive , Customer suspects for bank , we can print 2 pin mailer or 2 card . that is right ?)
It is the reason we need to do pin change with debit card at the first time when customer use card.
Aissa.Slimani
I m not sure to understand your algorithm!!
Also I m confused about using KA command to generate CVKA/B (Card Verification Key), KA Is to generate the KCV (Key Check Value)
Anyway try to change the Key Variant before the key CVK1+CVK2 in the translate command put (X,Y, U, T)
Aissa
De : jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] De la part de Chung vu
Envoyé : mercredi 17 juin
2009 02:22
À : jpos-...@googlegroups.com
Objet : Re: Data Migration !
Hi Aissa ,
More
information to Alissa :
In the past , i don't know how to generate double length for CVK and PVK and i
fowlow this rule when we have single :
3DES PVK=PVK1+PVK2
3DES CVK1=3DES
CVK2=CVKA+СVKB.
Both of key to generating .
Chung vu
KA is to generate encrypted CVKA and encrypted CVKB
Is it ZMK is double length ?
i cannot do so i use
3DES CVK1=3DES
CVK2=CVKA+СVKB.
Would you have any advise ?
for example :
Online-AUTH>ka
Encrypted CVK A: 7511 011B 9C8B 7533
Key check value: 1D76 31
Encrypted CVK B: A765 7BE9 E651 72F3
Key check value: E82A 81
Online-AUTH>ke
Enter key type: 402
Enter key scheme: x
Enter ZMK:
Enter key:
Data invalid; please re-enter:
Terminated
Aissa.Slimani
Ok , I see , i think you was using progammer API,
Try this please on the console :
Online - AUTH > IV
Key type [Pvk/Cvk]: C
Enter ZMK:
Enter key A:
Enter key B:
De : jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] De la part de Chung vu
Envoyé : mercredi 17 juin
2009 11:20
dinhc...@gmail.com
It is Key import commands , i want to export key
Thanks
On Jun 17, 6:50 pm, "Aissa.Slimani" <aissa.slim...@gmail.com> wrote:
> Ok , I see , i think you was using progammer API,
>
> Try this please on the console :
>
> Online - AUTH > IV
>
> Key type [Pvk/Cvk]: C
>
> Enter ZMK:
>
> Enter key A:
>
> Enter key B:
>
> _____
>
> Envoyé : mercredi 17 juin 2009 11:20
> À : jpos-...@googlegroups.com
> Objet : Re: Data Migration !
>
> Hi Aissa ,
>
> KA is to generate encrypted CVKA and encrypted CVKB
> Is it ZMK is double length ?
> i cannot do so i use
> 3DES CVK1=3DES
> CVK2=CVKA+СVKB.
> Would you have any advise ?
>
> for example :
> Online-AUTH>ka
>
> Encrypted CVK A: 7511 011B 9C8B 7533
> Key check value: 1D76 31
>
> Encrypted CVK B: A765 7BE9 E651 72F3
> Key check value: E82A 81
>
> Online-AUTH>ke
>
> Enter key type: 402
> Enter key scheme: x
> Enter ZMK:
> Enter key:
>
> Data invalid; please re-enter:
> Terminated
>
>
> I m not sure to understand your algorithm!!
>
> Also I m confused about using KA command to generate CVKA/B (Card Verification Key), KA Is to generate the KCV (Key Check Value)
>
> Anyway try to change the Key Variant before the key CVK1+CVK2 in the translate command put (X,Y, U, T)
>
> Aissa
>
> _____
>
> Envoyé : mercredi 17 juin 2009 02:22
>
> À : jpos-...@googlegroups.com
> Objet : Re: Data Migration !
>
> Hi Aissa ,
>
> More information to Alissa :
> In the past , i don't know how to generate double length for CVK and PVK and i fowlow this rule when we have single :
> 3DES PVK=PVK1+PVK2
> 3DES CVK1=3DES
> CVK2=CVKA+СVKB.
>
> With CVK , we use KA command to generage CVK A and CVKB .
>
> Both of key to generating .
>
> With the ZMK single length , i can export this key.
> But cvka and cvkb , to keep it securely , i use double length with algorithms in the past:
> CVK2=CVKA+СVKB
> I have a problem to export this CVK2 now .
> Would you have any idea ?
> Thanks
> Chung
>
>
> Chung,
>
> Nothing to be changed within the security config, as all used command does not involve clear pin operations. The HSM should of course be in the Authorized state.
>
> The process is 100% safe if the 1st step (ZMK exchange) is secured by 3 allowed persons/components both from your side and the other bank side.
>
> A i s s a.
>
> _____
>
> Envoyé : mardi 16 juin 2009 17:17
>
> À : jpos-...@googlegroups.com
> Objet : Re: Data Migration !
>
> Thanks Alissa so much
> i check HSM manual , I think your solution is okie .
> anything should be checked with initial security config (i am concerned with CS command)
> Thanks once more time
>
dinhc...@gmail.com
We use IBM method . with IBM methods to verify pin you use DA commands
and input inludes :
+ TPK
+ PVK
+ Pinblock
+ Offset
So to do data migration , we need take PVK and pin encrypted under LMK
02,03
From pin encrypted under LMK 02,03 , we hava offset value
Would you advise my idea ?
Regards,
Chung
On Jun 16, 8:10 pm, Gustavo Núñez <gustavo.nun...@adinet.com.uy>
wrote:
jason.sc...@gmail.com
Victor Salaman-Medina
--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
Join us in IRC at http://webchat.freenode.net/?channels=jpos
You received this message because you are subscribed to the "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/f98ef3f6-fe48-4619-8dc6-38c582119f9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.