Tag: sleutel

About sleutel

Subscribe Feeds

Kun je de stagiair aansprakelijk houden voor 600 te vervangen sloten?

Geplaatst op in Informatiemaatschappij, Privacy, 20 reacties

We kennen allemaal het stagiair-excuus: bij de meest uiteenlopende problemen (vaak de beschamende) wordt er dan gauw gezegd dat de stagiair het heeft gedaan. Lekker makkelijk, denk ik dan altijd, het is jóuw stagiair dus daar had je wel even mogen opletten. Maar bij dit Duitse geval weet ik het even niet. Deze stagiair was zo blij met zijn nieuwe werkplek dat hij trots via WhatsApp een foto stuurde naar zijn vrienden. Met de hoofdsleutel (loper) in zijn handen. En is dat een probleem? Eh ja, reageren nu alle securityminded lezers van deze blog: dan kunnen derden die foto gebruiken om de loper na te maken. Eh, echt, reageren nu de overige lezers. Ja, echt. En het ging hier om de hoofdsleutel van de gevangenis van Heidering (Duitsland).

Als je met een beetje recente smartphone een foto maakt, staat die standaard op een enorm aantal megapixels ingesteld. Deel je dat dan via WhatsApp of ander medium, dan gaan al die megapixels mee ook al toont je scherm maar een 13×5 centimeter versie. Maar 8 megapixels is bijvoorbeeld al tot 90×60 centimeter nog perfect op een poster te drukken, en met een béétje pixels dus meer dan een vierkante meter.

Zo’n formaat is méér dan genoeg voor een reproductie in een 3d printer, waar de app KeyMe reclame voor maakt. Of zoals hier met gewoon ouderwets knutselwerk en een blanco sleutel. Menig slotenmaker waarschuwt dan ook tegen het publiceren van zulke foto’s. (Oh ja, ook omdat veel eenvoudige sloten een genummerde sleutel hebben die je gewoon kunt bijbestellen.)

Omdat het hier gaat om de hoofdsleutel van een gevangenis, wil je geen risico lopen. Alle sloten vervangen dus, en dat is een dure grap: volgens experts kost zo’n omvangrijke operatie ongeveer 50.000 euro. Wat ik wel wil geloven, hoewel ik me wel af zit te vragen waarom juist in een gevangenis sleutels worden gebruikt die kennelijk zo makkelijk te kopiëren zijn. Er zijn immers ook beveiligde/gecertificeerde sloten, die bijvoorbeeld een chip van binnen hebben of aan twee kanten aparte patronen hebben. En dan is een foto van één zijde niet genoeg.

Afijn, de juridische vraag was dus of de kosten verhaald kunnen worden. Dat lijkt me sterk. Werknemers – en stagiairs rekenen we voor het gemak daaronder als dat zo uitkomt – zijn in principe namelijk gewoon niet aansprakelijk voor hun fouten, dat is de werkgever. Slechts bij opzet of bewuste roekeloosheid is verhalen mogelijk, en dat is een héle hoge lat. Bewust roekeloos is het juridisch gezien pas als je wist van het risico maar dacht dat de kans aanzienlijk groter was dat er niets zou gebeuren (Pollemans/Hoondert, voor de juristen). De werkgever moet minimaal kunnen aantonen dat objectief gezien de werknemer zich daadwerkelijk bewust moest zijn van het roekeloze karakter (Dieteren/Express).

Dat argument zie ik hier niet opgaan. Weliswaar wordt er dus op allerlei plekken gewaarschuwd voor dit risico, maar ik heb desondanks niet het idee dat ‘men’ in het algemeen dit weet, en dat is zo ongeveer wel wat je nodig hebt. Ik ken iemand die een tijdje de gewoonte had om bij Instagramfoto’s van sleutels bij nieuwe woningen (“Yesss op mezellef”) daar een 3d printje van op te sturen als waarschuwing. Maar dat werd nooit ontvangen als “oh ja da’s waar ook, slordig van me”.

Dit nog even los van het idiote idee dat een stagiair 50.000 euro heeft of dat iemand ermee geholpen is dat een stagiair jarenlang gaat betalen om dit goed te maken.

Arnoud

Niet bij je Bitcoins kunnen omdat de politie je telefoon heeft

Geplaatst op in Regulering, 8 reacties

Iets waar niet iedere Bitcoin bezitter rekening mee houdt, wat te doen als de politie je telefoon heeft? Dat las ik bij het onvolprezen Betablog. Hij wees op een recent strafvonnis waarbij de verdachte tegen precies dit probleem aanliep: “zegt de veroordeelde tegen zijn moeder dat hij over geld in Bitcoins beschikt, maar dat hij daar niet bij kan komen omdat de politie zijn telefoon in beslag heeft genomen.”

De veroordeelde is betrokken geweest bij het verhandelen van verdovende middelen op de darknet markets Dream Market en Nightmare Market onder de vendor namen DrugsTradeCenter en Mr.Ted, zo lees ik in het vonnis. Ik vermoed dat men deze persoon op het spoor kwam door een actie in 2020 van internationale opsporingsdiensten, waaronder Europol, tegen onder meer deze twee darknetmarkten. (Darknet is een lekenterm voor semi-anoniem communiceren en dan drugs per post sturen.)

Bij de verdachte werd een laptop aangetroffen met daarop de nodige administratie van de drugsverkoop, waaruit de rechter concludeert dat hij niet zomaar een naïeve loopjongen was. Ook hielp niet mee dat hij niet wilde aangeven wie dan de ‘achterman’ was en hoe hij dan wel aan zijn geld kwam. En dan heb je bij een ontnemingszaak echt een probleem gezien de omgekeerde bewijslast die dan geldt.

Ten slotte zijn ook twee tapgesprekken die de veroordeelde na zijn aanhouding vanuit de PI met zijn moeder heeft gevoerd veelzeggend. Daarin zegt de veroordeelde tegen zijn moeder dat hij over geld in bitcoins beschikt, maar dat hij daar niet bij kan komen omdat de politie zijn telefoon in beslag heeft genomen. De verklaring van de veroordeelde ter terechtzitting dat hij dit enkel heeft gezegd om stoer te doen is geenszins aannemelijk, omdat niet valt in te zien waarom hij tegenover zijn moeder uit stoerdoenerij zou liegen. Die strekking had dit gesprek in het geheel niet, zo valt uit de context op te maken.

Gezien het vorenstaande kan buiten redelijke twijfel worden vastgesteld dat de veroordeelde zelf van de drugshandel heeft geprofiteerd. En inderdaad is het wel een interessante dat je na zo’n inbeslagname (die is ter bevriezing voor het onderzoek) niet meer bij je geld, je bitcoins immers, zou kunnen. Ik zie daar niet direct een bezwaarmogelijkheid tegen, als de enige sleutel voor je geheime kluis aan een in beslag genomen sleutelring zit dan heb je ook even pech vermoed ik.

Arnoud

Mag ik de hardcoded sleutel van een app gebruiken voor mijn eigen aanroepen?

Geplaatst op in Ondernemingsvrijheid, 36 reacties

Een lezer vroeg me:

Ik wil gebruik maken van een online tool vanuit mijn eigen software. Helaas is een zakelijke licentie op die tool veel te duur. Nu zat ik in de bijbehorende app voor consumentengebruik te kijken, en die blijkt met een hardcoded key te authenticeren. Ik kan daarmee dus perfect een aanroep simuleren, want het http verkeer is ook nog eens onversleuteld. Is dit toegestaan?

Het is in principe de bedoeling dat je aangeboden tools gebruikt zoals ze je aangereikt worden. Dat staat niet letterlijk in de wet maar volgt volgens mij uit wat juristen de redelijkheid en billijkheid noemen. Maar daar staat tegenover dat het dus niet automatisch strafbaar of onrechtmatig is als je iets anders inzet dan de aangeboden tooling.

In het geval van de vraagsteller kun je die app zien als niet meer dan een schil waarmee een server wordt aangeroepen. Ik zie het onrechtmatige niet in het zelf doen van die aanroep. In dit geval wordt er geen account van een ander gebruikt of een achterdeurtje aangeroepen. Alle apps hebben dezelfde sleutel, dus waartegen die sleutel moet beveiligen is me een raadsel.

Ook vraag je op deze manier geen informatie op waar je geen recht op had. Je had exact deze gegevens gekregen als je via de app de informatie op had gevraagd. Van computervredebreuk – ergens binnengaan waar je weet dat je niet mag zijn – kan ik dus niet spreken hier. Wellicht als je de API gaat manipuleren door extra velden te proberen, of counters gaat veranderen buiten de range die de app zelf gebruikt. Dat zou ik dus afraden.

Een complicatie bij deze vraag is dat de aanbieder zakelijke licenties onderscheidt van consumentengebruik met de app. De werkwijze van deze vraagsteller leidt ertoe dat hij onder een consumentenmantel informatie krijgt die hij zakelijk gaat inzetten. Dat zou je kunnen zien als contractbreuk: er staat vast iets in de app-licentie dat de informatie uitsluitend huishoudelijk of privé gebruikt mag worden.

Daar staat voor mij tegenover dat de vraagsteller ook met de app in de hand de informatie had kunnen verkrijgen en dan zakelijk inzetten. Daar doet die app niets tegen. Ik zie de schade niet voor de aanbieder in dat geval, dus waarom zou het dan wél schadelijk zijn als hij dat met een eigen tool doet?

Arnoud

Apple moet encryptie-loper maken van Amerikaanse rechter

Geplaatst op in Innovatie, Regulering, 63 reacties

sleutel-key-encryptie-decryptieIn een rechtszaak waarin FBI eist dat Apple helpt om een iPhone te ontgrendelen, heeft de Amerikaanse overheid een klinkende overwinning behaald. Apple moet speciale software ontwikkelen om het iPhone-kraken te ondersteunen. Dat meldde Webwereld vorige week. De software is aangepaste firmware met als doel een bruteforceaanval op het wachtwoord mogelijk te maken.

De FBI heeft Apples hulp nodig, omdat de iPhone gebruikt is door een schutter in een schietpartij en men hoopt op het toestel bewijs te vergaren. Maar de telefoon is versleuteld, en zonder wachtwoord kom je er dan niet in. Ook Apple niet: er is geen master key of achterdeur ingebouwd.

Men zou natuurlijk het toestel kunnen brute forcen, alleen blokkeert een iPhone na tien pogingen. De eis van de FBI ging dan ook hierover: maak aangepaste firmware die niet na tien pogingen de boel vergrendelt. Zo kan de FBI gewoon alle mogelijke wachtwoorden uitproberen. Opmerkelijk vind ik nog dat de software mag zijn voorzien van een toestelspecifieke koppeling, zodat de FBI dit handige tooltje niet generiek kan inzetten op alle telefoons die ze vanaf nu vinden. Rechter met clue. Uit het bevel:

Apple’s reasonable technical assistance shall accomplish the following three important functions: (1) it will bypass or disable the auto-erase function whether or not it has been enabled; (2) it will enable the FBI to submit passcodes to the SUBJECT DEVICE for testing electronically via the physical device port, Bluetooth, Wi-Fi, or other protocol available on the SUBJECT DEVICE and (3) it will ensure that when the FBI submits passcodes to the SUBJECT DEVICE, software running on the device will not purposefully introduce any additional delay between passcode attempts beyond what is incurred by Apple hardware.

Het is in zoverre een noviteit dat het met versleutelde telefoons nog nooit geprobeerd is. Maar op zich heeft het een basis: de rechter kan nu ook al fabrikanten van apparatuur verplichten mee te werken aan het openen, ontgrendelen en dergelijke daarvan. Punt was alleen altijd dat dat meestal wat makkelijker was; een slotenmaker kan een loper hebben, een autofabrikant weet hoe de motorkap open moet en als dat alles faalt dan is er altijd wel iemand die zijn weg weet met een lasbrander. Het probleem is hier redelijk acuut, omdat er niemand anders is dan Apple die in staat is deze beveiliging te doorbreken.

Dit is dus niet hetzelfde als een achterdeur moeten inbouwen in de encryptie, iets dat de FBI al een hele tijd wil. Het is een tussenoplossing die schippert tussen de belangen van Apple en die van de opsporingsdiensten. Ik ben heel benieuwd of Apple daadwerkelijk met dergelijke software komt.

Arnoud

De toegangscode van een brandmelder opeisen

Geplaatst op in Informatiemaatschappij, 26 reacties

brandmelderIets dat we steeds vaker gaan zien: je wilt van je installateur of beheerder af, maar die heeft de toegangscodes of wachtwoorden en die wil hij niet zomaar afgeven. Sta je dan in je recht om ze op te eisen? Dat is een juridisch lastige vraag, want zo’n code is niets. Het is immers niet meer dan data. Maar in een recente rechtszaak vond de rechter toch een praktische oplossing.

Uit het vonnis blijkt dat een onderhoudsbureau een onderaannemer had ingehuurd die onder meer de brandmelder had geplaatst in het Rotterdam The Hague Airport Wings Hotel (hierna: “het hotel”, sorry wat een mond vol).

Die melder functioneerde niet naar behoren volgens de klant, maar de onderaannemer was stellig dat er niets aan de hand was. Weliswaar stond permanent het storingslampje aan, maar dat bleek een spookmelding te zijn zonder daadwerkelijke gevolgen. Ook kon een extern bureau geen grote problemen vinden. De rechter ziet dan ook geen problemen met de levering door die onderaannemer, dus die moet gewoon betaald krijgen voor zijn diensten.

Tussen de regels door krijg ik het gevoel dat het bureau klachten kreeg van het hotel omdat het ding maar bleef piepen of moeilijk doen. Zo ging de melder een keer af toen het buiten 45 graden was op een extra zonnige dag, of door douchestoom. Dus dan voelt het als een logische volgende stap om toch van die onderaannemer af te willen.

Met een ander verder gaan mag, ook als er geen echte klachten zijn. Maar nu wordt het ICT-spannend: wil je dat brandmeldsysteem onderhouden, dan heb je een code nodig (hierna: “de code”) en die wilde de onderaannemer niet zomaar afgeven. Na enig aandringen toch wel, maar dan alleen onder de volgende voorwaarden:

acceptatie van de gevolgen van de overdracht van de code aan een andere installateur door [het bureau];
verval van garantie en iedere aansprakelijkheid van [gedaagde1] voor de BMI;
afstand van aansprakelijkheid, korting of verrekening als gevolg van terugzetten code;
finale kwijting ter zake de BMI.

Dit zijn op zich gebruikelijke eisen. Alleen, mág je dat wel stellen als voorwaarde om een toegangscode, hierna: “de code”, te moeten afgeven? Nou nee, want nergens in het contract staat geregeld dat je alleen dan de code hoeft af te geven.

De spanning stijgt: op welke grond houdt de onderaannemer de code nu onder zich? De rechter komt uit bij het retentierecht. Je mag spullen onder je houden die van een ander zijn zolang die ander een afspraak niet nakomt. Alleen, in het contract stond dat het retentierecht niet ingezet mag worden, dus dat kan de onderaannemer vergeten. Code afgeven, einde oefening.

Echter, dit is wel raar, want het retentierecht geldt voor fysieke zaken en een toegangscode is dat niet. Oh pardon, toch wel:

Hierbij wordt opgemerkt dat de voorzieningenrechter de code beschouwt als een zaak als genoemd in artikel 3:290 juncto 3:2 BW, nu de code in deze gelijk te stellen aan een fysieke sleutel.

Dat klopt formeel niet helemaal, maar praktisch gezien wel. En voorzieningenrechters zijn er voor praktische oplossingen. En het is ergens ook wel te verdedigen dat een sleutel een zaak is: hij is voor menselijke beheersing vatbaar, vertegenwoordigt waarde en is in de praktijk uniek/verplaatsbaar. Codes deel je maar in beperkte mate en meestal is er maar een iemand die hem weet (als het goed is, wordt hij na overdracht snel gewijzigd immers). Dus dan klopt het ook formeel.

Arnoud

Ubisoft trekt betaalde speltoegangkeys in wegens parallelle import, mag dat?

Geplaatst op in Informatiemaatschappij, 21 reacties

ubisoft-key-spelUbisoft heeft keys ingetrokken die spelers bij niet-officiële retailers hebben gekocht, las ik bij Tweakers. Hiermee zijn deze spelers hun geld kwijt en kunnen ze het spel niet meer spelen. Ubisoft verwijst mensen naar de verkoper, kennelijk met het idee dat je daar maar je geld moet gaan terugvragen. Eh, mag dat, een sleutel even ongeldig verklaren?

Waarom Ubisoft bezwaar heeft tegen niet-officiële retailers, is me niet helemaal duidelijk. Het Tweakersartikel suggereert dat het gaat om activatiesleutels die van buiten de EU komen, waar de prijzen lager zijn. Ik kan me voorstellen dat Ubisoft dat niet leuk vindt, maar dit is wel een érg zwaar machtsmiddel om daartegen te ageren.

Maar is het legaal? Daar ben ik nog niet uit. Er is gewoon niets geregeld voor digitale sleutels of wachtwoorden die toegang geven tot een dienst.

Bij fysieke parallelle import is het vrij duidelijk: je mag zonder toestemming van de merkhouder geen merkproducten importeren van buiten de EU naar een EU-land. Is het eenmaal legaal in de EU op de markt gekomen, dan mag je het opkopen en doorverkopen binnen de EU, ongeacht wat de merkhouder daarvan vindt. Die partij dure parfum bij de Kruidvat ligt daar dus legaal maar er zit die dag een héle boze meneer bij het hoofdkantoor van dat merk. Hetzelfde geldt voor auteursrechten overigens.

In de VS is dat nog liberaler: uitputting geldt wereldwijd, oftewel als het ergens ter wereld geautoriseerd op de markt is gekomen, mag het geïmporteerd naar de VS en daar verhandeld zonder toestemming van de auteursrechthebbende. Voor merken zijn ze dan weer iets strenger, mits het product voor de internationale markt er anders uitziet dan voor de thuismarkt.

Voor diensten is dit eigenlijk nooit aan de orde geweest. Een dienst parallel importeren kán ook eigenlijk niet. Natuurlijk kan een dienstverlener leveren aan een klant in een ander land, maar daar is hij zelf bij dus dat is dan automatisch geautoriseerd.

Specifiek bij softwarediensten als deze kan het echter wél spelen, zoals de Ubisoft-zaak laat zien. En daar zit dus een lacune in de wet, want die zeggen niet of dit mag of niet. Ik ben geneigd te zeggen dat je dan wél sleutels overal mag kopen en inzetten. Wat niet verboden is, dat mag in het recht.

Natuurlijk, daar kun je van afwijken en dat gebeurt in de algemene voorwaarden dan ook vaak. Echter de Terms of Service van Ubisoft benoemen dit niet, hoewel ze wel een gezellige “alles is morgen anders”-clausule hebben:

We behouden ons het recht voor om deze Voorwaarden te wijzigen of een gedeelte of het gehele Puntensysteem te allen tijden te verwijderen, een en ander geheel naar eigen goeddunken, krachtens de voorwaarden die gespecificeerd zijn in artikel 17 hieronder.

Maar ook dan: die regels moeten er wel even zijn voordat je op die basis een sleutel ongeldig mag verklaren.

Dus nee: het mag niet, maar zoals altijd in het consumentenrecht, wat doe je eraan nu ze het toch doen?

Arnoud

Mag ik een NS-treinsleutel 3d printen?

Geplaatst op in Ondernemingsvrijheid, Regulering, Security, 48 reacties

treinsleutel-3d-printenEen lezer vroeg me:

De NS gebruikt een driekantsleutel (zie plaatje) om treindeuren te openen en sluiten. Volgens mij is het hebben van zon sleutel niet strafbaar. Maar mag ik nu voor geïnteresseerden een 3d cad bestand maken zodat ze voor hun privébezit zo’n sleutel mogen printen? Of ben ik dan aansprakelijk voor strafbare zaken die zij uithalen? Kan ik dat oplossen door bijvoorbeeld het bestand onder GPL vrij te geven? Daar staat immers een beperking van aansprakelijkheid in.

Een sleutel hebben (echt of nagemaakt) is inderdaad niet strafbaar. Het gebruiken van zo’n sleutel om ergens binnen te gaan wel, dat is lokaalvredebreuk en dat is een strafbaar feit. Specifiek een regel tegen het onbevoegd sluiten van treindeuren weet ik zo niet.

Een sleutel namaken is op zich niet strafbaar, tenzij je weet (of moet weten) dat de opdrachtgever met die sleutel strafbare feiten wil gaan plegen. Dan ben je immers medeplichtig.

Met een disclaimer of licentie met aansprakelijkheidsbeperking kom je er niet in die situatie. Of dat nu een opensourcelicentie is of een maatwerktekst. Net zo min als je vingers in je oren doen en heel hard LALALA zingen als de opdrachtgever uitlegt wat hij er mee gaat doen. De tekst uit de GPL zegt alleen dat de maker niet aansprakelijk is naar de gebruiker van de software, dus als iemands 3d printer oververhit en ontploft door dit model dan ben je beschermd via de licentie. Maar de NS heeft niets te maken met die tekst.

Als de sleutel ook een legitiem doel heeft (bv. verwarmingsradiatoren openen) en dat is serieus vol te houden, dan kun je het op die grond gooien. Maar zet er dan niet bij “Uiteraard niet bedoeld om de trein snel uit te komen ;)” of zo. Dan sta je wellicht toch weer strafbare feiten uit te lokken.

Kortom, het gaat niet per se om de sleutel of het 3d cad bestand waarmee de sleutel te printen is. Minstens zo belangrijk is hoe je dit presenteert, waartoe je mensen aanzet of uitlokt.

Arnoud

Wanneer is een API reverse engineeren computervredebreuk?

Geplaatst op in Security, 28 reacties

chip-paspoort.jpgEen lezer vroeg me:

Onlangs is de OV-Chipkaart app uitgekomen. Uit analyse blijkt dat de app per request een specifieke signature meestuurt, en zonder die signature komt er geen reactie vanuit de server van Trans Link Systems. De methode waarop de signature gemaakt wordt is te achterhalen met decompileren en daarna eenvoudig na te maken. Het is erg moeilijk te achterhalen door puur naar het verkeer te kijken. Mijn vraag is: als iemand API calls doet op basis van die kennis, is er dan sprake van computervredebreuk?

Als ik het goed begrijp, dan doet die app dus aanroepen op de server van TLS. Om te bewijzen dat de app echt de app is, wordt daarbij een signature/code gemaakt op basis van een sleutel die in de app aanwezig zit. Heb je de sleutel, dan kun je dus de code namaken en je eigen aanroepen als echt presenteren.

Van computervredebreuk is sprake als je binnendringt in andermans computer. Een ov-chipkaart is een computer, en die heb je te leen van TLS. Binnendringen daarin is dus mogelijk. Maar een app op je eigen telefoon, daar kun je niet in binnendringen. De app is geen ‘geautomatiseerd werk’, de telefoon wel maar die is van jezelf.

Binnendringen in de server van TLS is mogelijk en dat kan wel computervredebreuk zijn. Alleen, er moet dan sprake zijn van binnendringen zonder recht, wederrechtelijk dus. Je zegt dan, je mag inloggen met de app maar handmatig/eigen app inloggen mag niet. Ik twijfel of dat werkt. Als ik zeg “hier is de sleutel” en jij maakt een sleutel erbij, dan pleeg je geen huisvredebreuk als je met die extra sleutel binnengaat. Het gaat om de plek waar je mag zijn, niet het middel waarmee je daar komt. Een undocumented feature aanroepen door de API-URL te manipuleren (misschien doet &debug=1 iets leuks?) zou ik wel computervredebreuk noemen.

Auteursrechtelijk is het spannender. Je decompileert en achterhaalt de werking van de app. Als het doel dan is een kloon van de app te maken, dan botst dat met het auteursrecht op de app. Maar ‘kloon’ is een beperkt begrijp. En een nieuwe app die alleen dezelfde API calls doet, zou ik niet snel een ‘kloon’ noemen. De wet hanteert “computerprogramma, dat niet als een nieuw, oorspronkelijk werk kan worden aangemerkt” als criterium. Dus echt pure nabouw, dezelfde functionaliteit en layout.

Je kunt je ook afvragen of je wel de ‘werking’ van de app aan het achterhalen bent. Je wilt in feite alleen het algoritme voor het maken van de code achterhalen, en natuurlijk het element zelf dat daarvoor nodig is. Hoe de rest van de app werkt, is minder van belang.

Arnoud