Mullvad brengt fysieke beveiligingssleutel uit en zet broncode en ontwerp online

Vpn-dienst Mullvad brengt een fysieke beveiligingssleutel uit. Die is bedoeld om in te loggen met tweetrapsauthenticatie, maar de sleutel lijkt geen fido2 te ondersteunen. Zowel de software als het ontwerp van de sleutel is open source beschikbaar.

Mullvad heeft voor de verkoop van de sleutel een nieuw bedrijf genaamd Tillitis opgericht. Dat is meteen ook de naam van de sleutel. De Tillitis Key kan worden gebruikt om een time-based one time password of totp-code te genereren om in te loggen bij websites met 2fa. Mullvad zegt dat applicaties pas tijdens het gebruik op het apparaat worden geladen en daar dus niet persistent op blijven staan. Ook maakt de sleutel gebruik van een vorm van multiboot waarbij verschillende applicaties op de sleutel kunnen worden geladen zonder met elkaar in aanraking te komen. Mullvad schrijft in de documentatie dat de sleutel voor totp-log-ins, het verifiëren van software-integriteit en voor SSH-toegang kan worden gebruikt.

De Tillitis lijkt in ieder geval geen fido2- of WebAuthn-protocol te ondersteunen. Dat is een protocol dat bedrijven als tweetrapsauthenticatiemethode kunnen implementeren. Er zijn veel van zulke sleutels, zoals de bekende Yubikey of de SoloKey, die specifiek met die standaard in het achterhoofd ontworpen zijn. Tweakers nam eerder een aantal van die sleutels onder de loep. Mullvad noemt nergens in de documentatie ondersteuning voor die populaire protocollen.

Mullvad heeft zowel de software als de hardware openbaar beschikbaar gemaakt. Op GitHub staat naast de documentatie ook de code die op de sleutel draait, maar ook de schema's van het pcb en de fpga.

De sleutel wordt deze week gepresenteerd op de Open Source Firmware Conference. Vanaf dat moment is v1 van de sleutel ook te koop. De prijs is op dit moment onbekend. Het lijkt erop dat er vooralsnog alleen een USB-C-versie van de sleutel beschikbaar komt, maar in de documentatie staat dat daar wel een adapter voor USB-A wordt meegeleverd.

Mullvad Tillitis Key

Door Tijs Hofmans

Nieuwscoördinator

20-09-2022 • 07:44

51

Lees meer

Reacties (51)

Sorteer op:

Weergave:

Waarom zou je dit met een FPGA maken?
Software voor een normale MPU/CPU is een stuk makkelijker to controleren voor een groot publiek zonder specifieke FPGA kennis.
Het schrijven van constant time en power algoritmes is moeilijk en soms gewoon niet mogelijk op een cpu. Met een FPGA zijn er meer mogelijkheden.
Daarom gebruik je chips die daar specifiek voor ontworpen zijn: Secure Elements. Of MCU met een SE aan boord. Na dit gelezen te hebben was mijn vraag ook exact dezelfde als die @-=bas=- heeft.

Al is wel de vraag hier: Heb je veiligheid nodig tegen fysieke aanvallen. Ik denk het niet. Dan heb je dus geen SE nodig. Maar dan heb je ook geen constant time / power nodig. (Ja in theorie misschien constant time zodat die niet via USB poort bekeken kan worden door een aanvaller, maar laten we wel wezen, dat is triviaal te implementeren op elke MCU door gewoon een timertje te laten draaien voor je het antwoord geeft).
Daarom gebruik je chips die daar specifiek voor ontworpen zijn: Secure Elements. Of MCU met een SE aan boord. Na dit gelezen te hebben was mijn vraag ook exact dezelfde als die @ heeft.
Dan ben je gelimiteerd tot de algoritmes die die chip geïmplementeerd heeft, met een FPGA ben je veel flexibeler.
Al is wel de vraag hier: Heb je veiligheid nodig tegen fysieke aanvallen. Ik denk het niet.
Ik zou zeggen van wel, en zij zijn het daar mee eens want beveiliging tegen fysieke aanvallen zit in hun thread model. https://github.com/tillit...eat_model/threat_model.md
Beveiliging tegen fysieke aanvallen is volgens die link expliciet out of scope.
Niet toen ik de link plaatste :+
Maar zonder iets van pincode ben je toch genaaid lijkt mij als iemand die key in handen krijgt. Oke als je kan kopiëren heb je nog een verdergaand risico, maar je primaire probleem heb je al als iemand fysieke toegang heeft.

Als je dingen als kopiëren als risico ziet, dan lijkt het mij toch echt dat je veel beter af bent met secure elements / secure MCU.
Moeilijk voor open source als de programming manual en SDK achter een NDA zit.
Juist het punt van 2FA is dat je een fysieke, niet te kopiëren, sleutel hebt. Fysieke aanvallen zijn hier een essentieel onderdeel van.

Als je niet beschermt tegen fysieke aanvallen, kan je net zo goed gewoon de Google Authenticator op je smartphone draaien.
Verschil is dat die Google Authenticator (in theorie iig) gevoelig is voor een software aanval. Juist daarbij zou ik me niet zo druk maken over een hardware aanval, dat is wel behoorlijk afgschermd.

Maar goed, als je dus wel zorgen maakt daarover, dan is het logisch om een secure element te gebruiken in je ontwerp.
De applicatie-code heeft geen toegang tot de FPGA zelf. Je upload de applicatie naar een RISC-V core, waardoor je dus met precies hetzelfde probleem zit.
Het hele project is open-source gemaakt dus ook het PCB. Je kan het hele ding dus zelf produceren als je dat zou willen. De FPGA zal er dan mogelijk zijn omdat je zelf flexibel bent in welke chip je gebruikt en je kunt verilog laten reviewen terwijl dit met een willekeurige chip lastiger is.
Zo krijg je het product mogelijk erg goedkoop op de markt, wat het laagdrempeliger kan maken. Het laten reviewen zal een stuk lastiger zijn voor menig individu, maar de optie is er en als er iets mis is kun je hardware/software zelf aanpassen mocht je dat willen.
De FPGA zal er dan mogelijk zijn omdat je zelf flexibel bent in welke chip je gebruikt en je kunt verilog laten reviewen terwijl dit met een willekeurige chip lastiger is.
Maar bij een MCU kan je de C code (bijvoorbeeld) laten reviewen. Hoe is dit anders? Oké je kan stellen dat je niet weer of de MCU wel echt die C code draait, maar datzelfde kan je stellen over een FPGA. Instantieert die wel echt die Verilog code?
Ik neem aan dat het idee hier meer was dat je ook wijzigingen kunt maken aan de code, je dus niet vast zit aan een bepaalde (groep) leveranciers etc. Het idee lijkt te zijn dat alles maar dan ook alles zeer eenvoudig zonder enig probleem niet alleen onderzocht kan worden maar ook aangepast kan worden als je daar om welke reden dan ook zin in hebt. Als je bijvoorbeeld wel fido2- of WebAuthn-protocol ondersteuning wil hebben kun je dat waarschijnlijk dus ook gewoon implementeren.

Nu ken ik de wereld van de MCU markt helemaal niet maar ik kan me zo voorstellen dat als iemand anders de module maakt ze niet aan jan en alleman de C code willen leveren en daar vast wat voorwaarde zo als bepaalde aantallen afnemen of een vaste klanten programma aan verbinden. Ook lijkt het me sterk dat als ik een wijziging zou willen maken in de code van een MCU module dat ik dat zo maar even kan doen.

Mijn gok is dat men de keuze voor een FPGA gemaakt heeft omdat het een stuk makkelijker is om meer flexibiliteit te bieden. Maar zo als ik al zei ik weet weinig van deze markt dus het is een gok dus ik hoor graag als ik het helemaal niet goed begrepen heb (gebeurt bijna nooit natuurlijk :+ )
Wellicht te maken met kosten vs performance vs stroomgebruik? Een FPGA kan zover ik weet veel efficiënter specifieke taken uitvoeren waardoor je met minder krachtige hardware meer bereiken.

Pure speculatie vanuit mijn kant overigens.
Dan kan je niet alleen de software, maar ook de hardware (deels) updaten. Basically geeft het mullvad meer controle over de hele stack ipv er maar op vertrouwen dat de CPU niets lekt en compleet veilig is.
In essentie is dit een DIY secure element - ze emuleren een RISC-V core in de FPGA, en combineren dat met een soort TPM.

Het idee is dat de RISC-V core een extra register heeft voor de secret key, dat alleen toegankelijk is in de bootloader. Vanaf je PC laad je vervolgens een applicatie op de key. Volgens mij hasht de bootloader de applicatie, en gebruikt deze hash om van de token-brede key een applicatie-specifieke key te maken. De applicatie kan hier vervolgens allemaal leuke dingen mee doen.

Grappig concept, maar ik ben nog niet overtuigd.
Ten eerste zijn alle fysieke aanvallen "out of scope": als iemand dus kortstondig fysieke toegang heeft, is het relatief eenvoudig om er een kopie van te maken.
Hoewel je zelf applicaties kan uploaden, is de gegenereerde key uniek per applicatieversie. Applicatie-updates zijn dus niet mogelijk.
De token heeft geen counters, dus beveiliging tegen replay-attacks is onmogelijk.
De token bevat alleen een FPGA-based RNG - zeer waarschijnlijk dus van twijfelachtige kwaliteit.
Er lijkt geen mogelijkheid te zijn om secrets op te slaan - een eigen SSH key of TOTP op de token opslaan is daardoor waarschijnlijk niet mogelijk.
De token werkt via een serial-over-usb protocol en negeert alle bestaande standaarden. Dit zorgt er voor dat er altijd een custom applicatie nodig is op de PC, en dat integratie in bestaande software een heel stuk lastiger is.

Al met al dus niet echt bijzonder indrukwekkend. Qua veiligheidsniveau ziet dit er meer uit als een hobbyprojectje dan een serieus product. Zonder diepgaande analyse van een 3rd-party expert zal ik me hier in ieder geval niet aan branden!
Een voordeel van een FPGA kan zijn dat supply chain attacks makkelijker te voorkomen zijn. Het is moeilijk om een evil FPGA te maken die het doel van de hacker vervult met een bitstream die volledig willekeurig kan zijn. De bitstream zelf kan dan weer van source gemaakt worden met een betere audit trail dan hardware.

Voor wie dit interessant vind kan ik Bunnie’s blog van harte aanraden:
https://www.bunniestudios.com/blog/?p=5706
Nog nooit van gehoord ... maar lijkt me geen slecht idee zo een extra sleutel. Wel mooi dat het opensource is. Dacht wie weet toch eens kijken naar de prijs... werkt hun site gewoonweg niet. "This site can’t provide a secure connectionwww.mullvad.net sent an invalid response. ERR_SSL_PROTOCOL_ERROR". Dit zal em dus niet worden voor mij. Als je dit zelfs niet ziet of niet kan monitoren, dan heb ik er ook geen vertrouwen in dat de rest goed in elkaar zit
Nog nooit van gehoord ...
Mullvad (VPN) komt voor in PrivacyGuides (voorheen PrivacyTools).
Opvallend is hoe privacy bestendig het maken van een account is: alles gaat d.m.v. een gegenereerd nummer. Je email etc is niet nodig, en wordt niet om gevraagd.

Ook opvallend is om hoe weinig permissies de Mullvad vpn app vraagt, wat qua privacy uiteraard prettig is:
Other:
view network connections
full network access
En verder open source.

[Reactie gewijzigd door Cyb op 23 juli 2024 14:03]

Even een kleine waarschuwing, het orginele team achter privacytools (waar ik deel van ben) is verhuist naar https://privacyguides.org.

De enige die privacytools nu nog "onderhoud" is burung, en gezien de site nu vol zit met affiliate links, zou ik hun aanradingen met een korel zout nemen.

(Ik zeg hier trouwens niet dat je perse ons zou moeten volgen, maar alleen dat je op moet passen met je vertrouwen rondom privacytools ;)
Gelukkig geeft PrivacyTools nog wel aan of een link gesponsord of geaffilieerd is, maar het hele gebeuren rondom PrivacyTools haalt inderdaad wat vertrouwen weg. Ik heb mijn bericht er zojuist op aangepast.
Opvallend is hoe privacy bestendig het maken van een account is: alles gaat d.m.v. een gegenereerd nummer. Je email etc is niet nodig, en wordt niet om gevraagd.
Ja, daar wijst iedereen altijd op. En het feit dat je kan betalen door ze cash via de post te sturen, en dat hun clients open source zijn.

Al die best practices in de verifieerbare details leiden natuurlijk ook de aandacht af van het centrale feit dat niemand buiten Mullvad objectieve data heeft voor een educated guess omtrent het ene punt dat er echt te doet: loggen ze je data?

We hebben daar eigenlijk een nieuwe naam voor nodig, analoog aan security theater: best practices theater. Een manier om mensen impliciet te doen geloven in wat je beweert maar niet kan of wil bewijzen, door heel veel juiste signalen te sturen dat je de zaken aanpakt volgens wat het enthusiast milieu als de best practices beschouwt. Het enthusiast milieu is zich bewust van het probleem, maar het verlangen om minstens een product of dienst te consumeren i.p.v. helemaal niets te consumeren, doet ze het probleem negeren voor wie het best de best practices volgt.
Al die best practices in de verifieerbare details leiden natuurlijk ook de aandacht af van het centrale feit dat niemand buiten Mullvad objectieve data heeft voor een educated guess omtrent het ene punt dat er echt te doet: loggen ze je data?
Dat weten we dus wel. Mullvad is al op meerdere fronten ge-audit. Zie o.a. https://mullvad.net/nl/bl...logging-of-customer-data/
Jij weet dat wat een auditor vaststelt tijdens de momentopname die hij uitvoert van toepassing is op de servers waarmee Mullvad-klanten verbinding maken?
Jezus echt ja? Ga jij op deze manier een discussie aan?

Nee, dat weet ik niet nee. Maar dan is het simpel: jij vertrouwt niks en niemand totdat JIJ het met eigen ogen ziet. Niet specialisten, niet experts, niet artsen, whatever. Nee, JIJ moet het zien om te geloven.

Corona? Zal wel niet bestaan, ik heb het niet gehad. Poliovaccin? Werkt niet, nooit uitgetest of ik het krijg. Aarde plat? Ja natuurlijk, ik moet eerst naar de ISS om het met eigen ogen te zien of de aarde wel rond is.
Gelieve je te onthouden van persoonlijke aanvallen via stromanargumenten.

Wat ik zei is heel simpel: het feit dat bv. Mullvad zich aan heel wat best practices houdt, bewijst ten gronde niets omtrent hun betrouwbaarheid. Mensen maken aannames over een criterium dat ze niet kunnen verifiëren (hun logging policy, t.t.z. het enige dat er echt toe doet) op basis van de "vibes" die ze krijgen op basis van criteria die ze wel kunnen verifiëren. Dat is irrationeel en dient toch af en toe onder de aandacht gebracht te worden. Redenering geldt ook voor andere enthusiast brands zoals Protonmail inzake e-mail.

Edit: typo

[Reactie gewijzigd door EmbarrassedBit op 23 juli 2024 14:03]

Ik denk dat hij wil zeggen dat je feitelijk niemand kan vertrouwen als het er echt om spant.

Daarom moet je ook geen VPN gebruiken maar gewoon Tor als je echt iets te verbergen hebt.
Werkt bij mij gewoon hoor.
Misschien eerst even je eigen browser checken en kijken wat die precies voor melding geeft? Misschien zit er wel degelijk iets tussen jou en Mullvad dat je TLS verbinding verstoort. Dan wil je dat je die error krijgt, want daar is het voor gebouwd.
Ik ben toevallig vorige week van anderhalf jaar ExpressVPN overgestapt naar Mullvad. Moet zeggen dat ik prima tevreden ben! Netjes dat ze een vaste prijs hebben en goede features.
Idem. Ik ben overgestapt van PIA en heb er geen spijt van, ondanks dat Mullvad 2x zo duur is. Ik vond PIA traag en Mullvad totaal niet, ik haal gewoon (bijna) dezelfde snelheid als zonder vpn. Ze hoeven ook geen gegevens van je te hebben, ze doen niet aan username/password combo's. Tot op zekere hoogte dan, op het moment dat je de app opstart, hebben ze wel je originele ip-adres natuurlijk.
Prima VPN, dat Mullvad maar ben toch overgestapt naar IVPN. Net wat stabieler. Qua hardwarekey: ik weet het niet, waarom geen fido2? Ik gebruik nu een YubiKey en heb mijn zinnen gezet op een NitroKey 3 NFC. Geloof vooralsnog niet dat deze Tillitis daar iets aan gaat veranderen.
Hoe werkt deze sleutel dan?
Voor jullie security specialisten zou dit gesneden koek zijn, maar voor mij als hobbyist niet…
Ik ben bekend met Webauthn met public-private key en dat bijvoorbeeld ES256 een mogelijkheid is, maar bij deze sleutel ben ik benieuwd…

Edit : Ik zit het artikel nog even na te lezen. En ik begrijp hoe totp werkt, maar niet dat ie pas een programma gaat laden als je in probeert te loggen.

[Reactie gewijzigd door Hee_Martijn op 23 juli 2024 14:03]

Waarschijnlijk een vorm van challenge-response welke door de sleutel wordt gedaan.

Webbrowsers implementeren een Javascript API welke gebruikt kan maken van deze sleutel en welke gebruikt kan worden door websites voor authenticatie.

Nadeel lijkt mij wel dat je sleutel uniek is en dat je geen kopie kan maken. Als je de fysieke sleutel kwijtraakt dan kom je er niet meer in en moet je een nieuwe maken en alle websites waar je die sleutel gebruikte opnieuw instellen.
Wel jammer dat ze de firmware niet in Rust hebben geschreven, maar in C.

Rust vind ik tegenwoordig wel een "must" voor beveiligingsgerelateerde hardware en software.
Bij de naam 'Tillitis' heb ik niet het gevoel dat iemand van marketing hiernaar gekeken heeft. Voor de duidelijkheid:

Ti ll i tis
Ik snap (zelfs met je verduidelijking) niet waar je op doelt, wat is er precies slecht aan de naam?
Ik snap (zelfs met je verduidelijking) niet waar je op doelt, wat is er precies slecht aan de naam?
De leesbaarheid van zoveel op elkaar gelijkende karakters?
Het ligt aan het lettertype hoe (on)duidelijk het is om te lezen. Te veel i's en l's achter elkaar leest niet makkelijk.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 14:03]

Kan ook een taal dingetje zijn, aangezien tillit in het zweeds vertaald naar vertrouwen, maar geen idee of ze daar iets op hebben gebaseerd of niet
Mullvad is een Zweeds bedrijf, dus dat zou een goede verklaring zijn voor de naam. :)
Mullvad betekent mol in het Zweeds. VPN -> tunnel -> mol. En vandaar de mol in hun logo.
Dus De Mol bevindt zich in Zweden?
Misschien until it is?
Of juist wel, het is wel een opvallende naam. Het feit dat het ons nu opvalt en we het er over hebben betekent eigenlijk dat het werkt :)
Ik las dus serieus eerst tinnitus.
Ik hoorde precies hetzelfde :+
Mij doet het denken aan een ziekte ofzoiets.
A dirty mind is a joy forever.

Op dit item kan niet meer gereageerd worden.