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
- 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 .
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.
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:
> 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
> - 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 .
dinhchun...@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 .
Do you really store the PIN in an encrypted form?
> 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?
Hi Ono ,
Thanks for reply , below is my answer
Chug
On Tue, Jun 16, 2009 at 2:13 PM, ochomo <ocho...@gmail.com> wrote:
> 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 ?
> 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:
> > 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
> > - 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 .
On Tue, Jun 16, 2009 at 2:15 PM, Mark Salter <marksal...@talktalk.net>wrote:
> dinhchun...@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 .
> Do you really store the PIN in an encrypted form?
yes , i do . I see my vendor use Compare method to check pin .
> > This is my step i am thinking , would anybody give advise :
> > - We set HSM support clear pin
> Which HSM do you use?
We use Thales 8000
> > - 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 ?
> > - 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 ?
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 .
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'?
Please find bellow one way to do the requested task with Thales8000 :
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.
-----Message d'origine-----
De : jpos-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De la
part de Mark Salter
Envoyé : mardi 16 juin 2009 08:42
À : jpos-users@googlegroups.com
Objet : Re: Data Migration !
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 .
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'?
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
El Martes, 16 de Junio de 2009 01:55, dinhchun...@gmail.com escribió:
> 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
> - 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 .
> 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 :)
Hi Mark ,
Below is my answer !
Thanks a lot for your comment.
On Tue, Jun 16, 2009 at 3:42 PM, Mark Salter <marksal...@talktalk.net>wrote:
> 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 .
> 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?
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 .
> >>> - 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?
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.
> 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'?
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
On Tue, Jun 16, 2009 at 7:45 PM, Aissa.Slimani <aissa.slim...@gmail.com>wrote:
> Please find bellow one way to do the requested task with Thales8000 :
> 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.
> -----Message d'origine-----
> De : jpos-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De
> la
> part de Mark Salter
> Envoyé : mardi 16 juin 2009 08:42
> À : jpos-users@googlegroups.com
> Objet : Re: Data Migration !
> 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 .
> 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'?
On Tue, Jun 16, 2009 at 8:10 PM, Gustavo Núñez <gustavo.nun...@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 ?
> 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
> El Martes, 16 de Junio de 2009 01:55, dinhchun...@gmail.com escribió:
> > 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
> > - 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 .
Chung vu wrote: >> 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.
>> 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 .
A PIN offset is the 'distance' from the natural PIN the current PIN is.
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.
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
> 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 ?
> 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
> 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
> El Martes, 16 de Junio de 2009 01:55, dinhchun...@gmail.com escribió: > > 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 > > - 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 .
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-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De la
part de Chung vu
Envoyé : mardi 16 juin 2009 17:17
À : jpos-users@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
On Tue, Jun 16, 2009 at 7:45 PM, Aissa.Slimani <aissa.slim...@gmail.com>
wrote:
Please find bellow one way to do the requested task with Thales8000 :
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.
-----Message d'origine-----
De : jpos-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De la
part de Mark Salter
Envoyé : mardi 16 juin 2009 08:42
À : jpos-users@googlegroups.com
Objet : Re: Data Migration !
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 .
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'?
Hi Aissa ,
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
On Wed, Jun 17, 2009 at 2:14 AM, Aissa.Slimani <aissa.slim...@gmail.com>wrote:
> 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-users@googlegroups.com [mailto:jpos-users@googlegroups.com] *De
> la part de* Chung vu
> *Envoyé :* mardi 16 juin 2009 17:17
> 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
> On Tue, Jun 16, 2009 at 7:45 PM, Aissa.Slimani <aissa.slim...@gmail.com>
> wrote:
> Please find bellow one way to do the requested task with Thales8000 :
> 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.
> -----Message d'origine-----
> De : jpos-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De
> la
> part de Mark Salter
> Envoyé : mardi 16 juin 2009 08:42
> À : jpos-users@googlegroups.com
> Objet : Re: Data Migration !
> 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 .
> 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'?
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.
> 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 1^st 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-users@googlegroups.com [mailto: > jpos-users@googlegroups.com ] *De la part de* Chung vu
> *Envoyé :* mardi 16 juin 2009 17:17
> *À :* jpos-users@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
> On Tue, Jun 16, 2009 at 7:45 PM, Aissa.Slimani > <aissa.slim...@gmail.com <mailto:aissa.slim...@gmail.com>> wrote:
> Please find bellow one way to do the requested task with Thales8000 :
> 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.
> -----Message d'origine-----
> De : jpos-users@googlegroups.com <mailto:jpos-users@googlegroups.com> > [mailto:jpos-users@googlegroups.com > <mailto:jpos-users@googlegroups.com>] De la
> part de Mark Salter
> Envoyé : mardi 16 juin 2009 08:42
> À : jpos-users@googlegroups.com <mailto:jpos-users@googlegroups.com>
> Objet : Re: Data Migration !
> 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 .
> 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'?
gustavo.nun...@adinet.com.uy wrote:
> Sorry, I don't know your method.-
> 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).
Mark and I are explained in this mail . It demonstrate that Pin stored in Database is Pin encryted under Lmk 02,03
> b) Availability of cryptographic parameters (old and eventually new).
I don't understand. I
> c) Availability of testing environment (ATM, testing network, HSM, > etc)
ATM : Diebold , Wincord,
HSM : Thales 8000
> d) The cost of programming inside your switch (do you have to do all > this stuff in TAL ???)
I don't undertand .
> You should consider the cost of re-issuing cards. This could be the > cleanest solution.
I don't want to reissue due to we don't have a lot of ATMs , it is not convinent for Pin change . If new card deliver to customer with old balance , it is risky
(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.
> --------------------------------------------------------------------------- -------------------
> 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 ?
>> 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
>> El Martes, 16 de Junio de 2009 01:55, dinhchun...@gmail.com
> escribió:
>>> 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
>>> - 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 .
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-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De la part de Chung vu
Envoyé : mercredi 17 juin 2009 02:22
À : jpos-users@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
On Wed, Jun 17, 2009 at 2:14 AM, Aissa.Slimani <aissa.slim...@gmail.com> 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-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De la part de Chung vu
Envoyé : mardi 16 juin 2009 17:17
À : jpos-users@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
On Tue, Jun 16, 2009 at 7:45 PM, Aissa.Slimani <aissa.slim...@gmail.com> wrote:
Please find bellow one way to do the requested task with Thales8000 :
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.
-----Message d'origine-----
De : jpos-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De la
part de Mark Salter
Envoyé : mardi 16 juin 2009 08:42
À : jpos-users@googlegroups.com
Objet : Re: Data Migration !
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 .
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'?
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 ?
> 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-users@googlegroups.com [mailto:jpos-users@googlegroups.com] *De
> la part de* Chung vu
> *Envoyé :* mercredi 17 juin 2009 02:22
> *À :* jpos-users@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
> On Wed, Jun 17, 2009 at 2:14 AM, Aissa.Slimani <aissa.slim...@gmail.com>
> 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-users@googlegroups.com [mailto:jpos-users@googlegroups.com] *De
> la part de* Chung vu
> *Envoyé :* mardi 16 juin 2009 17:17
> 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
> On Tue, Jun 16, 2009 at 7:45 PM, Aissa.Slimani <aissa.slim...@gmail.com>
> wrote:
> Please find bellow one way to do the requested task with Thales8000 :
> 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.
> -----Message d'origine-----
> De : jpos-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De
> la
> part de Mark Salter
> Envoyé : mardi 16 juin 2009 08:42
> À : jpos-users@googlegroups.com
> Objet : Re: Data Migration !
> 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 .
> 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'?
De : jpos-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De la part de Chung vu
Envoyé : mercredi 17 juin 2009 11:20
À : jpos-users@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 ?
Enter key type: 402
Enter key scheme: x
Enter ZMK:
Enter key:
Data invalid; please re-enter:
Terminated
On Wed, Jun 17, 2009 at 5:43 PM, Aissa.Slimani <aissa.slim...@gmail.com> wrote:
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-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De la part de Chung vu
Envoyé : mercredi 17 juin 2009 02:22
À : jpos-users@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
On Wed, Jun 17, 2009 at 2:14 AM, Aissa.Slimani <aissa.slim...@gmail.com> 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-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De la part de Chung vu
Envoyé : mardi 16 juin 2009 17:17
À : jpos-users@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
On Tue, Jun 16, 2009 at 7:45 PM, Aissa.Slimani <aissa.slim...@gmail.com> wrote:
Please find bellow one way to do the requested task with Thales8000 :
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.
-----Message d'origine-----
De : jpos-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De la
part de Mark Salter
Envoyé : mardi 16 juin 2009 08:42
À : jpos-users@googlegroups.com
Objet : Re: Data Migration !
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 .
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'?
> 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-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De la part de Chung vu
> Envoyé : mercredi 17 juin 2009 11:20
> À : jpos-users@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 ?
> Enter key type: 402
> Enter key scheme: x
> Enter ZMK:
> Enter key:
> Data invalid; please re-enter:
> Terminated
> On Wed, Jun 17, 2009 at 5:43 PM, Aissa.Slimani <aissa.slim...@gmail.com> wrote:
> 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-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De la part de Chung vu
> Envoyé : mercredi 17 juin 2009 02:22
> À : jpos-users@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
> On Wed, Jun 17, 2009 at 2:14 AM, Aissa.Slimani <aissa.slim...@gmail.com> 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-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De la part de Chung vu
> Envoyé : mardi 16 juin 2009 17:17
> À : jpos-users@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
> On Tue, Jun 16, 2009 at 7:45 PM, Aissa.Slimani <aissa.slim...@gmail.com> wrote:
> Please find bellow one way to do the requested task with Thales8000 :
> 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.
> -----Message d'origine-----
> De : jpos-users@googlegroups.com [mailto:jpos-users@googlegroups.com] De la
> part de Mark Salter
> Envoyé : mardi 16 juin 2009 08:42
> À : jpos-users@googlegroups.com
> Objet : Re: Data Migration !
> 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 .
> 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'?
> 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
> El Martes, 16 de Junio de 2009 01:55, dinhchun...@gmail.com escribió:
> > 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
> > - 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 .
|
