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

| AE 11944 | 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

| AE 8442 | 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

| AE 8080 | 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?

| AE 7389 | Informatiemaatschappij | 21 reacties

Ubisoft 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… Lees verder

Mag ik een NS-treinsleutel 3d printen?

| AE 6423 | Ondernemingsvrijheid, Regulering, Security | 47 reacties

Een 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… Lees verder

Wanneer is een API reverse engineeren computervredebreuk?

| AE 6374 | Security | 27 reacties

Een 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…. Lees verder