Of course, PKG should be protected tightly, which is normally equipped with HSM. On the other hand, this risk is not unique to PKG. Same risk and security requirements apply to CA's certificate signing key. In fact, PKG's key generation process is exactly a signing process with master key signing on identity and other info.
Michael Benjamin Kaduk <bka...@akamai.com> 于2019年3月25日周一 下午11:36写道： > On Mon, Mar 25, 2019 at 10:07:05PM +0800, michael cheng wrote: > > > > > > As for the key escrow problem frequently raised in the emails, indeed, > > there is a PKG in the system which could generate each device's private > > key. However, when IBS is used in TLS1.3, passively attack to recover the > > session key is not possible. Actively man-in-the-middle attack by > replacing > > exchanged DH tokens and signatures would certainly leave traces even > > transiently. Similarly, a PKG could impersonate an entity to conduct a > TLS > > session, just as the KMS in the symmetric key solution, but forensic > traces > > could be also collected in this situation. It would be hugely risky for a > > PKG, which would usually be a trusted party, to launch such attacks. If > > such an attack is caught in red-handed, no one would trust the PKG's > > service anymore. > > The risk here is not just limited to the PKG violating the trust placed > in it -- there is also new attack surface on the PKG itself, and the > risk that the PKG could become operationally compromised and an attacker > obtain secrets in that manner. > > -Ben >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
