Scott Fluhrer (sfluhrer) writes: > The main reason we wouldn’t have considered that is a possible > complication to crypto hardware; if we assume that we had hardware > that did most of the crypto calculations internally, it might keep > the SK_d value internally, and might not give us an easy way to > modify it. In contrast, the nonces are inputs to the hardware, and > so that hardware is agnostic to whether we’re actually giving it the > nonces that actually appeared in the packets, or whether we’re > giving them modified versions of it.
One of the issues of using Ni' = PRF(PPK, Ni) instead of modifying the SK_d calculation is that the system needs to keep the PPK in memory permanently. I.e., if we only modify the SK_d calculation, i.e., define SK_d' = PRF(PPK, SK_d) or something like that, then we can clear the PPK in memory immediately after that point, and we can drop permissions that allows us access to PPK. This will provide better security as attacks similar to the heartbleed cannot read PPK from the memory. Also it is clear that even if PPK is changed during the lifetime of the IKE SA we do not enter the issue that whether we need to use old or new PPK. Especially if some kind of HSM is used to keep PPK, it might not allow access the old PPKs after they are expired. I think the PPK is so important that when you are adding support for the QR to your implementation you want to move the PPK handing in to the hardware crypto module so PPK will be protected, and not add it as addon to the crypto module. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
