Hey there! My name is Ravi, and I am an independent advisor. I am happy to help you. :) I understand you're trying to log into your laptop but it's locked by BitLocker. If a user doesn't have a BitLocker Key, there's no way to bypass it. The only option is to do a clean Windows installation that will delete everything. A user can find the BitLocker Key from the same account used to activate it. Open a web browser on another device. Go to https://account.microsoft.com[...] to find your recovery key. If your device was ever signed into an organization using a work or school email account, your recovery key may be stored in that organization's Azure AD account. You can check all possible places to find a BitLocker Key here: https://support.microsoft.com[...] Important: Microsoft support is unable to provide, or recreate, a lost BitLocker recovery key. Feel free to get in touch again if you have any additional questions. Cheers, Ravi måske forsøget værd? https://www.partitionwizard.com[...]
--
jep jep
--

Sidst redigeret 02-07-2024 15:03

Hvis der ikke findes en recovery key, så kan du godt glemme at få adgang til drevet.
--
http://xlinx.dk[...] i7 2600K, 16GB PC3-12800, GA-Z68XP-UD4 R1, GTX 560Ti HAWK, 250GB 840 EVO

okay tak for svar, var desværre det jeg var bange for :(
--
life is guuut :D

Jeg plejer at bruge Bitlocker til at rense diske med, hvis jeg ikke har en Dban boot usb i nærheden.
--

Du kan prøve at skrive til NSA. De har en bagdør i Bitlocker ;) Spøg til side, har du mulighed for at sætte disken en anden maskine? Eller hvordan opføre den sig?
--

Hej. Hele pointen med bitlocker er at kryptere din harddisk for a beskytte din data mod F.eks at nogen stjæler din laptop og vil kopiere data ud fra disken. havde der været en “smutvej” til at slå bitlocker fra ville funktionen være meningsløs. hvis du ikke har recovery Keys til bitlocker må du desværre se det data som slettet/forsvundet, det kan ikke genskabes uden. de har ikke tilfældigvis OneDrive vel? Normalt laver dem backup af standard bruger foldere nutildags
--

#OP Hvis ikke du kan faa liv I den gamle TPM chip og ikke har en recovery key saa er der ikke mget at goere. men hvis du kan faa liv i den gamle TPM chip kan koden hentes ud med diverse sjove programmer #4 dumb metode Brug diskpart clean all I stedet for. Mere sikkert. #6 Hvis nogen stjaeler en laptop er det muligt at hive key ud af TPM chip og afkode disken. Det er mere til naer HDD bliver separate fra harddisk. Det er natuligvis ikke her og fru jensen der kan goere det.
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

Det lyder helt tosset at der skal en recovery key til, som er genereret af Microsoft. Havde det nu været en kode kendt af brugeren, som var kørt igennem en hash algoritme (sha512 etc), så var problemet løst. Så kunne den blot aflæses på en nye computer. Så er #0, out of luck. Han kan evt. tage computeren til reperation. Det kan være nogle simple og billige komponenter der er brændt af/kortsluttet.
--

#8 Hvad er det du mener helt praecist er tosset? En bruger kan ikke indtaste en noegle til bitlocker foer OS er loadet. Os kan ikke loades naar disken er krypteret saa for en OS disk bliver krypteringsnoeglen lagt I TPM chip og BRUGEREN faar en recovery key. Denne recovery key kan blive backet up automatisk paa din Microsoft konto. I dette tilfaelde er OP loebe ind i en del daarlige vaener 1: Bruger har ikke gemt deres noegle 2: Bruger har ikke lavet backup af deres noegle 3: TPM chip er I udu Der ville ikke vaer forskel om bruger havde et kode ord (hvilket jo storset er det samme som den gevet recovery key. noeget du skal huske) Hvis de har valgt at gemme og ikke tage backup af et kodeord ville det vaere det samme. Derefter saa ville du ALDRIG koer et kodeord igennem sha512 alene for at skabe en kryptreings noegle. Der er simpelthent for hurtigt og der er ikke bruge for 512bits til en 128/256 bit noegle Det virker altsaa lidt som om du laver lidt buzzword dropping uden at vide hvordan kryptering virker
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury
--

Sidst redigeret 03-07-2024 05:41

Jeg kender overordnet og grundlæggende til hvordan kryptering virker, men dykker du ned i de matematiske algoritmer, kommer jeg til kort. Jeg kender ikke det helt store til Bitlocker, men derimod Cryptsetup på Linux. Jeg køre selv med aes-xts-plain64 og 512 bit cipher key (derfor jeg bruger sha512 til password). Jeg har 2 keyslot aktiveret, en med kode og en med nøgle-fil. Hvis en fejler, kan jeg altid falde tilbage. Jeg har lige indsendt min bærbar til reparation og derfor flyttet min krypteret OS disk over i en anden bærbar. Jeg indtaster koden ved boot og køre videre. Det er netop det #0 ikke kan og derfor mener jeg det er helt tosset, at miste data på den måde. Microsoft kunne vælge at gøre det samme for deres Bitlocker, ved at oprette en kendt kode brugeren kan falde tilbage til. Et keyslot med TPM key kan samtidig godt eksistere. Designet med Recovery key ser jeg mere gavne Microsoft, der åbner op for at høste Bitlocker adgang og brugerdata i form af en Microsoft konto (giver en key, profilering kan samles omkring). Jeg er bekendt med Recovery filen kan gemmes lokalt på andet medie eller printes ud. Men det er nu besværligt og ikke ret brugervenligt kontra en kode brugeren kender. Koden kunne dog endda køres igennem sha256/512 (for at undgå cleartekst) og gemmes på medie/printes ud for maksimalt sikkerhed. Med tanke om at Microsoft gerne vil tvinge Bitlocker ned over brugerne med den kommende Recall funktion, åbner det op for store datatab for den uopmærksomme bruger. Jeg synes godt nok det er helt ude i hampen og ja et tosset system :)
--

Sidst redigeret 03-07-2024 09:32

Kan se man By-pass TPM og i stedet oprette et password der skal tastes ind hver gang systemet startes. Så Bitlocker har funktionaliteten, men ikke noget der er let tilgængeligt. Det kræver Gpedit. Men der oprettes stadig en Recovery key, så går der noget galt, er man stadig prisgivet i den situation såfrem man ikke har backup af nøglen. Kan se recovery key kun består af tal. Gad vide om den kan bruteforces. Det skal da undersøges nærmer :)
--

Men som sagt tidligere, så ligger kodeord også på ens MS profil under https://myaccount.microsoft.com[...] så der kan man være heldig at den står der.
--

#12 You can't sign in here with a personal account. Use your work or school account instead.
--

#7 kører disk part clean all en zero på hele disken? #8 Bitlocker understøtter også en valgfri kode ved boot uden brug af TPM chip og andet, der låser den til et specifikt system.
--

#14, det fandt jeg ud af. Der skal du ind i Gpedit :)
--

#10 hvad du siger et hellt 100% ikke korrekt. "Jeg køre selv med aes-xts-plain64 og 512 bit cipher key (derfor jeg bruger sha512 til password" lad os bbryde denn her ned AES - du bruger AES synkron cyrpterings metode. ogsaa har kun en key cipher size paa 128,192,og 256bits. Saa dette her passer altsaa ikke "512 bit cipher key" du kan ikke vaer AES hvis du har en 512bit cipher eller omvend AES har ikke en 512bit Cipher key mulighed. XTS - dette er din metode til hvordfna krypterings bleve lagt paa data og XTS er ganske fin til HDD kryptering. samme som bitlocker bruger i windows after 7. (win 7 bruger CBC mode med elefant diffuer extra lgtin) XTS bruger halvedlen af den gevets bits til din AES cipher key i dit setup. Det er her du forveklser 512 bits med hvad du har a cipher keys. din cipher key er 256bits men din XTS "key" er 512bits SHA512 kan blive brugt til at genere dine key fra et password men det re et elendig valg. SHA512 er hashing og ikke en keyderivation function. forskellen ligger i formaal og ressource brug en hashging algortime er til at verificer dette og en formaal ydover god entropy spredning er at den skal vaere "hurtigt" jo hurtiger (uden tab af andne funktionalitet) jo bedre end KDF er omvendts. en KDF skal vare saa langsom og ressource kravende som muligt for netop at goer det svaere at bruge password baseret bruteforcing samt dens accelered version sasom dictionary sizes Gode KDF idag er argon2 eller PKDB hvis du du er et sted der skal audites efter standar soem DOD og NIST. hvis ikke kan du evt ogsaa bruge Brcrypt og Scypt. jeg vil personligt altid anbefale argon2 pga den er isaer robust imod GPU hardware som f.eks sha2 absolut IKKE er. SHa 2 blierr du brugt flitte som message digest for digital signature i f.esk TLS kort opsumering 1 Det er ikke din cipherkey der er 512 bits. AES tager kun op til 256bits. 2: hvis du bruger sha2 til key generation goer du noget temmeligt elendigt setup. Jeg vil tro du bruger noget bedre men har mistforstaet hvor du bruger sha512. og det er din hash/digets key og ikke din til cipher key generation "Det er netop det #0 ikke kan og derfor mener jeg det er helt tosset, at miste data på den måde" Hvad sker hvis du har glemt din password ? og ikke har gemt din noeglefil Det er simpelhent det der er sket her. OP's kunde har ikke gemt ders passwor/noegle fil. om det er en recovery key eller et password er helt 100% det samme. om det er noegelfil eller gemt den recovery fil de faa saa er det igen det samme saa igen hvad er du du mener eder er tosset ved at man ikke kan komme til sine kryptere data naar man ikke har sin "secret"? Den eneste forskel er her at OP's kunde OGSAA har en ders key gemt i en TPM som en EXTRA mulighed ud over password og noegelfil. du har saa valgt udelukkende at bare afhaenging af TPM til at haandter krypterings noeglen saa hvis man lige faor at ojebliek stopper med *nix fanatikken. sa vil du see at det er intet tosset i hvad microsoft har lavet her og hvad du snakker burtde foreggar er praecist hvad der foregik. blot bruger fejl og intet med haandtret af kryptering der er galt. "Men det er nu besværligt og ikke ret brugervenligt kontra en kode brugeren kender. Koden kunne dog endda køres igennem sha256/512 (for at undgå cleartekst) " Det er svaert mere brugevenligt end at lade TPM haandter det hele og ikke skulle taenke over haandtering i det hele. det faktum at du skal indtaste dit krypterings password i din egen sitatuion er mere bruger uvenligt. spoegs hr og fru jense om det helst vil havde det automatisk eller skal huske et kode ord hvergang. og igen sha512 burde ikke bruger som KDF. Det er en skidt metode for at undgaa cleartext SHa512 kan simpelt "brydes" med rainbow tables saa er det irrelevant om det var brugt i clear text text eller ej "Med tanke om at Microsoft gerne vil tvinge Bitlocker ned over brugerne" Hvor gommer denne nye ting fra. OP's bruger havde helt frihed ove det. igen lyder dette her some mere nix fanatism en noget der har hold i den virkelige verden
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#11 Du kan brute force alting du har offline adgang til Igen det lyder som om du virkelige proeve at hakke paa microsoft over *nix fanatisme #14 JA og fordelen er her at du ogsaa tager MB/GPUID med i svinget Ved bitlocker kyrptering goer du det langsommere (flaskehalse vil udligne dette) da du skal bruge extra cpu krafter paa krypteringen. og ved bitlocker har du ren matemetistk 1/128^2 chance for at gaette krypterings noeglen med mdirne du koer med din aes paa 56bit saa er det naturligvis 1/256^2 I begge tilfaelde er det det hoejre end 0 chance ved overskrivning opsumering: mindre ressource brug. lidt bedre sikkerhed
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#10 Jeg glemte disse 2 " Jeg har 2 keyslot aktiveret, en med kode og en med nøgle-fil. Hvis en fejler, kan jeg altid falde tilbage." Igen det er jo NETOP hvad de har via deres microsoft bruger konto. Saa ALLE de ting du naevner mangler... ER til stede. "en kode brugeren kende" Jeg gaa ud fra her du mener her lavet som er nemt at huske.. fordi de kender jo koden hvis de havde husket at gemme den. Problemmet her med idn loesniing er et bruger generet koder er typeisk elendig entropy maessigt. hvilket netop er grunde til at vi bruger dictionary attacks. Dette er NETOP grunde til at vi bruger KDF som tidligere naevnt for at sloeve kodeord til key generations tiden. saa hvis vi tager dine anbefalinger her som angievet saa vil vi havde 1: et risiko for at svagt password 2: en elendig KDF function 3: intet salt ( du naevnte det aldrig) Det er en perfekt opskrift for elendig kryptering der er nemt af lave password brute forcing paa. absolut ikke en god maade at haandtere data sikkehed paa
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#16, jeg tror gerne du vil misforstå det jeg skriver. Jeg bruger Cipher key på 512bits ved aes-xts-plain64. Jeg har på intet tidspunkt skrevet jeg bruger mere end AES256, som er begrænsningen for algoritmen. By default a 512 bit key-size is used for XTS ciphers. Note however that XTS splits the supplied key in half, so this results in AES-256 being used. https://wiki.archlinux.org[...] Min password er genereret ud fra et saltet SHA512, dvs. matchende bits og dermed maksimal sikkerhed og ingen svage punkter. Jeg kan let generere det +100 karakter password, ud fra et mindre kompliceret password. Header fra Cryptsetup luks: Data segments: 0: crypt offset: 16777216 [bytes] length: (whole device) cipher: aes-xts-plain64 sector: 512 [bytes] Keyslots: 0: luks2 Key: 512 bits Priority: normal Cipher: aes-xts-plain64 Cipher key: 512 bits PBKDF: argon2i Time cost: 18 Memory: 1048576 Threads: 4 Salt: ea 7e d2 81 4e 46 20 e2 b5 43 f3 e5 15 86 1e 40 28 9d aa 29 26 da 44 e1 78 b3 ed 59 90 1d 14 8e AF stripes: 4000 AF hash: sha512 Area offset:32768 [bytes] Area length:258048 [bytes] Digest ID: 0 (...) om det er en recovery key eller et password er helt 100% det samme. Det bliver vi ikke enige om. Password har du tilknytning til (noget du ved), kontra en recovery key (noget du har). Jeg vil altid foretrække password da det kan genskabes. Det andet kan mistes uigenkaldeligt - både nøgle-fil, TPM, Recovery key etc. Igen det lyder som om du virkelige proeve at hakke paa microsoft over *nix fanatisme Jeg er kritisk overfor Microsofts valg og synes det er med rette. Det er #0 desværre eksempel på. Der er plads til klar forbedring. Omvendt virker du meget beskyttende overfor alt hvad der hedder Microsoft :)
--

#0 Hvis bitlocker recovery koden ikke ligger i brugerens egen MS konto, så er der god chance for at den ligger enten i Azure/Entra, eller på en AD server ved hans firma. Det er de to steder jeg ville grave eller rette en forespørgsel. Hvis altså det er en firma bærbar, eller han på noget tidspunkt har logget ind med sin 365 arbejdskonto/joinet den til AD domæne. Kan selvfølgeligt også være han har oprettet det med en usb pind, som så er forsvundet, men det kunne han evt. lede efter
--
Du er altid velkommen til at sende en besked hvis jeg ikke ser din kommentar
--

Sidst redigeret 03-07-2024 17:18

Hvor gommer denne nye ting fra. OP's bruger havde helt frihed ove det. igen lyder dette her some mere nix fanatism en noget der har hold i den virkelige verden Windows 11 24H2 will enable BitLocker encryption for everyone — happens on both clean installs and reinstalls https://www.tomshardware.com[...]
--

Sidst redigeret 03-07-2024 17:18

#10 Glemmer du ikke hele idéen med root of trust. Du tager din harddisk og sætter i en ny pc, indtaster password for at dekryptere og køre videre. Fint og alt vel - hvis du ikke vil have hardware root of trust. Jeg synes du kigger på problematikken ud fra et "forkert" synspunkt, når du kommer med din kritik. Skal man f.eks. indtaste et password, kan krypteringssoftwaren jo ikke umiddelbart stole på, hvem der indtaster koden. Fra krypteringssoftwarens synspunkt, kan det jo være en bandit, der har fået fat i passwordet f.eks. via Keylogger. Eller harddisken er blevet installeret i en pc med noget mellemliggende hardware/software, som manipulere med passwordet. Så fra harddiskens synspunkt kan den hverken stole på dit password eller på den hardware, du har installeret din harddisk i. Når du gør, som du gør og opfatter det som sikkert, er det fordi du ved at du indtaster det rigtige password. Det ved harddisken/krypteringssoftwaren bare ikke. Den eneste måde harddisken/krypteringssoftwaren kan være (noget nær) sikker på noget, skal der ikke komme noget "udefra" f.eks. password fra brugeren, men fra et sted i et "lukket" system" Et "lukket system" du som bruger ikke er en del af. Når jeg skrev tidligere skrev forkert i anførselstegn, skyldes det, at jeg synes din kritik er forkert ud fra en sikkerhedsmæssigt synspunkt, men rigtig ud fra en bruger-synspunkt. Hvilket vel egentlig skitsere en fundamental problematik mellem 2 konkurrerende behov: for sikkerhed og brugervenlighed. I OPs eksempel er problematikken jo så opstået grundet manglende kendskab til at bruge systemet og den funktionalitet, den tilbyder. F.eks. lave en recovery-key. Havde vedkommende haft sin recovery-key, havde der ikke været noget problem, vel? Skal man så også kritisere en løsning, der baserer sig på f.eks. password, hvis brugeren glemmer sit password? P.S. Jeg ved ikke specielt meget om den slags, så det er bare et par strø-tanker jeg giver.
--

#22 Det ene er ikke nødvendigvis mere sikkert end det andet, da sikkerheden ligger i implementeringen. En harddisk er "dum", og derfor kan den ikke se, hvad der forsøger at få adgang til den. En hardware-baseret RoT (eks. TPM), kræver et software-lag, som kan manipuleres. Uanset om en drev er krypteret med eller uden RoT-hardware, så kan det falde for et "brute force" angreb. Hvis et drev er krypteret med hardware-baseret RoT, og denne hardware går kaput, så mister man den legitime adgang til sine krypterede data, med mindre man har en recovery-nøgle. Har man en recovery-nøgle, som kan omgå RoT, så er RoT jo i og for sig allerede sat ud af kraft. RoT = Root of Trust.
--
http://xlinx.dk[...] i7 2600K, 16GB PC3-12800, GA-Z68XP-UD4 R1, GTX 560Ti HAWK, 250GB 840 EVO

#23 Skulle det have været mere sikkert, skulle der naturligvis ikke have været muligt at lave en recovery-key. Så det viser jo konflikten mellem sikkerhed og brugervenlighed. Jeg bruger harddisken som illustration af synsvinkel.
--

Sidst redigeret 04-07-2024 15:17

#22, jeg er enig med dig i, at sikkerhed strækker sig meget længere end password og recovery-key. Der er mange scenarier der skal tages stilling til og der er forskellige use-cases. Mit kritikpunkt hos Microsoft går hovedsageligt på at der kun er to indgange til deres kryptering default. Begge er "noget du har" (TPM/Recovery-key). Det gør krypteringen yderst sårbar, kontra et password "noget du ved". Bitlocker har dog mulighed for password+recovery-fil, men er ikke default - som du rigtig nok siger, brugervenlighed vinder over sikkerhed hos Microsoft. Ved at kombinere password og key-file så har du begge indgange: "noget du ved" og "noget du har", som er muligt i Linux verdenen. Luks har mulighed for op til 8 keyslot - dvs. du også kunne koble TPM på. 3 indgange giver 3 angrebsvektor, så det skal naturligvis opvejes i forhod til sikkerheds risiko. Fra krypteringssoftwarens synspunkt Jeg kan ikke helt følge dig her. Kan du prøve at uddybe? TPM'en ved heller ikke hvem der trykkede på start-knappen. Det kan være banditten har fået fysisk adgang til maskinen. Har du først fysisk adgang til en TPM maskine er løbet kørt, kontra et password giver en ekstra sikkerhed i den henseende.
--

#25 Jeg bruger krypteringssoftwaren som repræsentant for et sikkert, lukket system, der ikke er afhængig af eller kan by-pass´ noget udefrakommende, f.eks. password eller som Nitroblast jo så rigtigt skriver - en recovery-key. Og det er et lukket system qua RoT.
--

#26, det forstod jeg ikke så meget af :)
--

#27 Man skal vel indtaste det password, du ønsker dig, ind et eller andet sted. Så der skal et password ind i et lukket system, bestående af del-elementer, der stoler på hinanden. Et password, der kan være indtastet af dig eller en bandit, der har set dig over skulderen eller har haft en key-logger o.s.v. Sværere er min pointe sådan set ikke :)
--

#28, okay jeg forstår din pointe. Det du omtaler handler ikke så meget om krypteringen, men derimod sikkerheden omrking krypteringen. Der er der fordele og ulemper ved begge dele. Tyven kan også stjæle dit lukket system (bærbar etc) og have adgang, kontra ingen adgang ved password. Men der er omvendt risiko for brugeren bliver udsat for adpresning, vold, trusler mv. for at tilegne sig password'et. Men så er vi over i en anden snak, end det min kritik gik på :)
--

#29 Ja, Bitlocker reducere ikke alle risici som den ikke har lovet :)
--

#30, hvilke risici har Bitlocker lovet at reducere?
--

#31 Risicien for uautoriseret adgang til data.
--

#32, hvilket også har resulteret i en autoriseret bruger har mistet sin adgang til data ved simpel hardwarefejl. Recovery key kunne vel have været genereret på baggrund af noget brugeren kender ;)
--