Puncte:1

Cea mai bună practică pentru a crea o cheie de instalare în stil vechi

drapel ps
vsz

Toate cele mai bune practici actuale despre crearea și utilizarea cheilor criptografice pe care le-am găsit se referă la crearea unor date criptate din date brute. Cu toate acestea, există (sau cel puțin a existat în urmă cu câteva decenii) o practică în care o cheie nu este folosită pentru a decripta sau autentifica nimic, este folosită exclusiv local ca dovadă (de o săptămână) de proprietate.

În zilele de dinainte de internet, când cumpărai un software, îl primeai pe un suport fizic (floppy disk sau CD) și era imprimată fizic o „cheie” pe care trebuia să o introduci în timpul instalării. Nu a fost nevoie de conexiune la internet, nu a existat un server care să autentifice ceva sau să verifice dacă cheia a fost deja folosită. Instalatorul a verificat doar dacă cheia se conformează unor reguli care puteau distinge cheile valide de cele invalide.

Oricine putea să copieze cheia de la un proprietar legitim și să instaleze software-ul fără autorizație, nimic nu împiedica această practică, dar astfel de chei erau încă folosite pentru că nu toată lumea o făcea, prin urmare, a împiedicat cel puțin o parte a bazei de utilizatori să o pirateze. .

Dacă se face astăzi, într-un mediu complet offline, cum ar trebui creată în mod ideal o astfel de cheie? Nu ar trebui să fie prea lung, astfel încât să poată fi introdus manual în timpul instalării și ar trebui să existe în continuare milioane de combinații posibile. Cu toate acestea, ar trebui să fie foarte puțin probabil ca o mică modificare aleatorie a unei chei valide să aibă ca rezultat o altă cheie validă.

O abordare naivă ar fi aceea că jumătate din biții cheii sunt o constantă secretă predeterminată, cealaltă jumătate sunt aleatorii, dar sunt amestecați în conformitate cu o anumită logică și o sumă de control este, de asemenea, amestecată. Încă funcționabil pentru scopul propus și probabil a fost utilizat pe scară largă. Cu toate acestea, există abordări moderne și mai bune pentru crearea unor astfel de „chei de instalare offline”?

kelalaka avatar
drapel in
Hackerii vor găsi întotdeauna o modalitate de a ocoli protecția cheii dvs., atâta timp cât aplicația dvs. este viabilă. Vezi în industria jocurilor de noroc.
drapel ps
vsz
@kelalaka: bineînțeles că da, nu am spus niciodată că nu, dar dacă 100% din baza de utilizatori se bazează pe hackeri, vor fi mulți pentru cine funcționează. Doar pentru că un hoț suficient de motivat ar putea deschide orice lacăt, nu înseamnă că nu ar trebui să ne încuim niciodată ușile.
Puncte:2
drapel my

Cu toate acestea, există abordări moderne și mai bune pentru crearea unor astfel de „chei de instalare offline”?

Există două abordări evidente:

  • Una este să utilizați un cod de autentificare a mesajelor (MAC); acesta este un algoritm criptografic care preia un șir și o cheie secretă și generează o „etichetă”; ideea este că, fără a cunoaște cheia secretă, este greu să generezi o altă pereche șir/tag care validează.

Deci, ceea ce ați face ca producător este să selectați o cheie secretă aleatorie (pe care ați introduce-o în produsele dvs.). Pentru a genera o „cheie de produs” (etichetă care este atașată produsului), veți lua un număr de secvență, îl rulați prin MAC pentru a genera o etichetă și faceți ca numărul de secvență și eticheta să fie cheia de produs.

Apoi, când produsul este instalat, utilizatorul introduce cheia produsului; software-ul separă numărul de secvență și eticheta; apoi rulează numărul de secvență prin MAC (folosind cheia secretă pe care a introdus-o producătorul) și compară acea etichetă calculată cu eticheta care se afla în cheia de produs - dacă se potrivesc, continuați cu instalarea.

Avantajele sunt că acest lucru este ușor și că lungimea cheii de produs poate fi controlată cu ușurință (cu un MAC bun, să zicem, HMAC, o etichetă de 20 de biți va face ca probabilitatea de ghicire aleatorie să fie mai mică de unu la un milion pe ghicire - dacă nu este suficient de scăzut, alegeți doar o etichetă mai lungă).

Dezavantajul este că, dacă un hacker bun îți dezactivează produsul, poate extrage cheia secretă și apoi poate genera propriile chei de produs după bunul plac. Au existat încercări de a proiecta implementări care sunt rezistente la acest lucru („criptografie cutie albă”); acestea s-au dovedit a fi dezamăgitoare. Cu toate acestea, dacă efortul implicat din partea atacatorului este mai mult decât efortul de a distribui doar cheia de produs bună cunoscută, ar putea fi acceptabil.

  • Cealaltă abordare ar fi să mergeți cu un algoritm de semnătură cu cheie publică (cu o semnătură scurtă).

Această idee este similară, cu excepția faptului că producătorul generează o pereche de chei publice/private și inserează cheia publică pe dispozitiv.

Producătorul folosește cheia privată pentru a genera „chei de produs”; la instalare, software-ul folosește copia sa a cheii publice pentru a valida cheia de produs.

Avantajul este că nu mai trebuie să ne facem griji că un hacker va avea capacitatea de a crea noi chei de produs - pentru a face asta, are nevoie de cheia privată, iar aceasta nu este pe dispozitiv.

Dezavantajul este lungimea etichetei - chiar și algoritmii cu cea mai scurtă semnătură (care cred că este BLS) au încă semnături moderat lungi (de exemplu, 256 de biți pentru 100 de biți de securitate); și spre deosebire de cazul MAC, acestea nu pot fi trunchiate.

Au fost companii care au folosit semnături pentru cheile lor de produs - mă aștept că erau în minoritate.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.