Generarea perechii de chei RSA și stocarea numai a cheii private PKCS#11

Am observat că PKCS#11 acceptă C_GenerateKey funcția pentru taste simetrice și pentru asimetrice există doar C_GenerateKeyPair funcţie. Deci, din definiție, aceasta ne permite să le creăm doar pe ambele perechea cheie privată/cheie publică. Din înțelegerea mea, cheia privată stochează informații despre cheia publică (modul și exponent public), care sunt necesare pentru crearea cheii publice, astfel încât să poată fi preluată de fiecare dată pentru a genera cheia publică.

Pentru utilizarea mea, am nevoie doar de cheia privată din stocarea token-ului și nu prea am nevoie de cheia publică până la o utilizare viitoare.

Există dezavantaje dacă stochez doar cheia privată și generez cheia publică de fiecare dată când am nevoie de ea?

Cel mai evident: performanța.

Știu că SPHINCS+ este un exemplu în care generarea cheii publice din cheia privată este deosebit de costisitoare, pot exista alte scheme în care acest lucru este adevărat, dar nu cunosc niciuna.

De asemenea, deoarece vorbim despre hardware-urile PKCS#11 și am menționat acum semnătura apatridă bazată pe hash SPHINCS+, ar trebui să menționăm, de asemenea, că NIST a aprobat implementari hardware de XMSS și LMS cu stare semnături bazate pe hash.

Abordarea dvs. poate fi aplicată numai pentru RSA și numai dacă utilizați chei generate conform versiunii PKCS#11 >= 2.40. Standardul PKCS#11 definește (secțiunea 2.1.3 „Obiecte cheie privată RSA” din specificația de bază 3.0): „În vigoare cu versiunea 2.40, tokenurile TREBUIE să stocheze și CKA_PUBLIC_EXPONENT”.

Prin urmare, puteți obține modulul și atributele exponentului public (C_GetAttributeValue) și puteți crea un obiect cheie publică din acesta folosind C_CreateObject. Dar, după cum a subliniat DannyNiu, acest lucru cu siguranță costă performanță.

În funcție de simbol, este posibil să puteți utiliza obiectul cheie privată în loc de cheia publică pentru operațiuni precum C_Encrypt* sau C_Verify*, deoarece simbolul va folosi doar atributele publice.

Pentru alte chei asimetrice, de ex. Chei EC, nu există o definiție similară cu cea pentru RSA din standardul PKCS#11. Prin urmare, nu vor fi stocate piese publice. Va depinde de token dacă cheia publică este calculată din mers (confirmând comentariul lui Conrado). Acest lucru are cu siguranță un impact și mai mare asupra performanței. Dacă jetonul nu o face automat, nu există nicio modalitate de a declanșa calculul unei chei publice dintr-o cheie privată din PKCS#11.Și, desigur, nu ar trebui să o faceți niciodată extern - de ce ați folosi un token (HSM) dacă folosiți cheia privată în mod simplu în exterior?

În cele din urmă, dacă utilizați aplicații standard abordarea dvs. va eșua, deoarece aplicațiile adaugă adesea CKA_CLASS=CKO_PUBLIC_KEY la șablonul de căutare atunci când caută cheia publică pe care doresc să o utilizeze.