Il 07/02/22 12:49, Marco Bodrato ha scritto:
Ciao, Il Lun, 7 Febbraio 2022 12:03 pm, Roberto Resoli ha scritto:Il motivo per cui si usano coppie di chiavi diverse per identificazione e firma digitale è che nel primo caso vengono firmate quantità randomiche generato nell'ambito di un processo informatico (es: TLS). Mentre nel caso della firma si firmano quantità (documenti con valore legale) su cui il firmatario impegna la propria identità accettando il non disconoscimento (il "non repudiation" del campo keyUsage, appunto). Imho l'uso di coppie di chiavi pensate per identificazione come chiavi di firma digitale è del tutto improprio.Concordo. Usare la stessa coppia di chiavi sia per firmare che per identificarsi è decisamente pericoloso. Nel firmare un documento, di fatto praticamente sempre si firma l'impronta (Hash) del documento stesso. Con il linguaggio usato da Roberto, questa impronta è apparentemente una "quantità randomica". Semplificando molto, durante il processo informatico (es:TLS) di identificazione, l'utente di fatto si trova a firmare la "quantità randomica" inviata dall'interlocutore presso il quale si sta identificando, senza (alcuna possibilità di) verificarne il contenuto. Che succede se l'interlocutore, invece di mandarci una genuina "quantità randomica" ci manda l'impronta di un documento? Usando la stessa chiave per firmare e per identificarsi, si concederebbe la possibilità, a chi controlla i processi di identificazione, di ottenere firme su documenti arbitrari...
Cfr. ad esempio "X.509 V.3 Certificate Profile for Certificates Issued to Natural Persons" https://www.etsi.org/deliver/etsi_ts/102200_102299/102280/01.01.01_60/ts_102280v010101p.pdf: "Security note:Combining the non-repudiation bit (bit 1) in the keyUsage certificate extension with other keyUsage bits may have security implications depending on the security environment in which the certificate is to be used. If the subject's environment can be fully controlled and trusted, then there are no specific security implications. For example, in cases where the subject is fully confident about exactly which data is signed or cases where the subject is fully confident about the security characteristics of the authentication protocol being used. If the subject's environment is not fully controlled or not fully trusted, then unintentional signing of commitments is possible. Examples include the use of badly formed authentication exchanges and the use of a rogue software component. If untrusted environments are used by a subject, these security implications can be limited through use of the following measures: - to not combine non-repudiation key usage setting in certificates with any other key usage setting and to use the corresponding private key only with this certificate; - to limit the use of private keys associated with certificates that have the non-repudiation key usage bit set, to environments which are considered adequately controlled and trustworthy"
rob