I have a number of questions regarding Key Serial Numbers (KSNs) in DUKPT:
- KSNs are 8 - 10 bytes long. Older implementation are 8 bytes whereas newer ones are 10 bytes. Do I risk being incompatible with some old system if I create 10 bytes long KSNs?
- KSNs have 3 components: a 21 bits transaction counter and remaining bits are for key set ID and Tamper Resistant Security Module (TRSM) ID. For an 8 byte KSN the typical convention is 24 bits for key set ID and 19 bits for TRSM ID. This means around 16M Base Derivation Keys (BDKs) and 500K devices. To me this allocation has pros and cons. The cons are that I will never have 16M BDKs and if the business is successful it is quite possible to have > 500K devices. The advantage is that it forces us to not use the same BDK on more than 500K devices which limits exposure of one BDK being compromised. I do read that there is flexibility in how many bits are allocated to key set ID vs TRSM ID. So I'm tempted to swap the allocation such that we can have up to 500K BDKs and 16M devices. But I also see many open source implementations of DUKPT that assume 24-19-21 bits split. Those implementations would all break if I don’t follow the convention. Would you recommend that I just stick to convention?
- Is there some standard way for setting the key set IDs or does every entity owning a BDK come up with its own convention? Can I assign key set ID = 1 to my very first BDK ever and then increment it by 1 for each new BDK? Or is that strategy too naive?
- Is there some standard way for setting the TRSM ID? Can I assign TRSM ID = 1 for the very first device injected using a new BDK and then increment it by 1 for each new BDK?