/dev/null
- Overig
Device tijd differentiatie te gebruiken als rsa-pubkey
08-09-2022, 21:17 door Anoniem, 17 reacties
Na aanleiding van mijn idee in de nu door hemzelf afgesloten draad van de gewaardeerde Erik van Straten een volgende link:
(Dit n.a.v. een opmerking van mijn persoontje daar).
https://content.cisco.com/chapter.sjs?uri=/searchable/chapter/content/en/us/td/docs/ion-en_US/ios-xml/ios/security/m1/sec-m1-cr-book/reauthentication_time_through_rsa_pubkey.html.xml
Mijn idee was de subtiele tijd-differentiatie op devices te kunnen gebruiken als een authenticatie methode bij aanloggen.
Elk device heeft een minime afwijking op de tijd van het netwerk/atoomklok.
Is dit werkbaar voor in een modulair encryptie model?
Graag iemands commentaar.
Met dank aan Erik van Straten voor alles wat hij doet om mensen aan het denken te zetten.
Erik, je bent een reus!
luntrus
(Dit n.a.v. een opmerking van mijn persoontje daar).
https://content.cisco.com/chapter.sjs?uri=/searchable/chapter/content/en/us/td/docs/ion-en_US/ios-xml/ios/security/m1/sec-m1-cr-book/reauthentication_time_through_rsa_pubkey.html.xml
Mijn idee was de subtiele tijd-differentiatie op devices te kunnen gebruiken als een authenticatie methode bij aanloggen.
Elk device heeft een minime afwijking op de tijd van het netwerk/atoomklok.
Is dit werkbaar voor in een modulair encryptie model?
Graag iemands commentaar.
Met dank aan Erik van Straten voor alles wat hij doet om mensen aan het denken te zetten.
Erik, je bent een reus!
luntrus
Reacties (17)
Door Anoniem: Mijn idee was de subtiele tijd-differentiatie op devices te kunnen gebruiken als een authenticatie methode bij aanloggen.
lk device heeft een minime afwijking op de tijd van het netwerk/atoomklok.
Is dit werkbaar voor in een modulair encryptie model?
Graag iemands commentaar.
Het lijkt me niet.lk device heeft een minime afwijking op de tijd van het netwerk/atoomklok.
Is dit werkbaar voor in een modulair encryptie model?
Graag iemands commentaar.
Ten eerste weet je wel dat er een afwijking is van de atoomtijd, maar je weet niet hoe groot die is. Als je dat wel zou weten zou de systeemklok namelijk perfect gelijk gezet kunnen worden en was die afwijking er niet. Als je niet weet hoe groot de afwijking is dan kan je hem ook niet gebruiken als herkenningsmiddel.
Ten tweede is de afwijking op een computer van de atoomtijd niet constant en ook niet voorspelbaar. Computers gebruiken NTP om periodiek de tijd bij een NTP-server op te vragen. Afwijkingen worden gecorrigeerd, ofwel door de tijd te laten verspringen ofwel door de systeemklok wat langzamer of sneller te laten lopen om zo het verschil zonder sprongen in de systeemtijd weg te werken. Daarbij kan een NTP-client ook nog eens af en toe overstappen naar NTP-server die op dat moment aangeeft een nauwkeuriger tijdsignaal te hebben, en als bij zo'n overgang de NTP-servers niet helemaal gelijk lopen heeft de NTP-client opeens een verschil met de server die hij nu gebruikt weg te werken. Je kan niet voorspellen hoe dat gaat lopen, omdat het mede afhangt van wat allerlei andere servers elders in de wereld van moment tot moment doen. En als je het allemaal niet kan voorspellen dan valt er ook niet iets te herkennen, en dat heb je wel nodig voor authenticatie.
Ten derde zou het makkelijk te vervalsen zijn, als het technisch gezien al bruikbaar zou zijn. Een aanvaller die weet hoe het werkt hoeft alleen maar via malware de relevante karakteristieken van de tijd op de aangevallen computer op te pakken om die op een ander systeem na te bootsen om daarmee ergens binnen te kunnen dringen. Geen goed idee.
Door Anoniem:
Ten eerste weet je wel dat er een afwijking is van de atoomtijd, maar je weet niet hoe groot die is. Als je dat wel zou weten zou de systeemklok namelijk perfect gelijk gezet kunnen worden en was die afwijking er niet. Als je niet weet hoe groot de afwijking is dan kan je hem ook niet gebruiken als herkenningsmiddel.
Ten tweede is de afwijking op een computer van de atoomtijd niet constant en ook niet voorspelbaar. Computers gebruiken NTP om periodiek de tijd bij een NTP-server op te vragen. Afwijkingen worden gecorrigeerd, ofwel door de tijd te laten verspringen ofwel door de systeemklok wat langzamer of sneller te laten lopen om zo het verschil zonder sprongen in de systeemtijd weg te werken. Daarbij kan een NTP-client ook nog eens af en toe overstappen naar NTP-server die op dat moment aangeeft een nauwkeuriger tijdsignaal te hebben, en als bij zo'n overgang de NTP-servers niet helemaal gelijk lopen heeft de NTP-client opeens een verschil met de server die hij nu gebruikt weg te werken. Je kan niet voorspellen hoe dat gaat lopen, omdat het mede afhangt van wat allerlei andere servers elders in de wereld van moment tot moment doen. En als je het allemaal niet kan voorspellen dan valt er ook niet iets te herkennen, en dat heb je wel nodig voor authenticatie.
Ten derde zou het makkelijk te vervalsen zijn, als het technisch gezien al bruikbaar zou zijn. Een aanvaller die weet hoe het werkt hoeft alleen maar via malware de relevante karakteristieken van de tijd op de aangevallen computer op te pakken om die op een ander systeem na te bootsen om daarmee ergens binnen te kunnen dringen. Geen goed idee.
Dat was mijn eerste gedachte ook: hoe kan je een tijdverschil als referentie gebruiken als zowel de bron (atoomklok?) als de systeemtijd continue driften?Door Anoniem: Mijn idee was de subtiele tijd-differentiatie op devices te kunnen gebruiken als een authenticatie methode bij aanloggen.
lk device heeft een minime afwijking op de tijd van het netwerk/atoomklok.
Is dit werkbaar voor in een modulair encryptie model?
Graag iemands commentaar.
Het lijkt me niet.lk device heeft een minime afwijking op de tijd van het netwerk/atoomklok.
Is dit werkbaar voor in een modulair encryptie model?
Graag iemands commentaar.
Ten eerste weet je wel dat er een afwijking is van de atoomtijd, maar je weet niet hoe groot die is. Als je dat wel zou weten zou de systeemklok namelijk perfect gelijk gezet kunnen worden en was die afwijking er niet. Als je niet weet hoe groot de afwijking is dan kan je hem ook niet gebruiken als herkenningsmiddel.
Ten tweede is de afwijking op een computer van de atoomtijd niet constant en ook niet voorspelbaar. Computers gebruiken NTP om periodiek de tijd bij een NTP-server op te vragen. Afwijkingen worden gecorrigeerd, ofwel door de tijd te laten verspringen ofwel door de systeemklok wat langzamer of sneller te laten lopen om zo het verschil zonder sprongen in de systeemtijd weg te werken. Daarbij kan een NTP-client ook nog eens af en toe overstappen naar NTP-server die op dat moment aangeeft een nauwkeuriger tijdsignaal te hebben, en als bij zo'n overgang de NTP-servers niet helemaal gelijk lopen heeft de NTP-client opeens een verschil met de server die hij nu gebruikt weg te werken. Je kan niet voorspellen hoe dat gaat lopen, omdat het mede afhangt van wat allerlei andere servers elders in de wereld van moment tot moment doen. En als je het allemaal niet kan voorspellen dan valt er ook niet iets te herkennen, en dat heb je wel nodig voor authenticatie.
Ten derde zou het makkelijk te vervalsen zijn, als het technisch gezien al bruikbaar zou zijn. Een aanvaller die weet hoe het werkt hoeft alleen maar via malware de relevante karakteristieken van de tijd op de aangevallen computer op te pakken om die op een ander systeem na te bootsen om daarmee ergens binnen te kunnen dringen. Geen goed idee.
Ook atoomklokken zijn niet altijd identiek, luister daarvoor bv. eens naar de fantastisch interessante presentatie van Bert Hubert op de MCH2022: https://media.ccc.de/v/mch2022-17-how-do-gps-galileo-really-work-how-the-galmon-eu-monitors-all-navigation-satellites waarin hij bv. beschrijft waarom GPS satteliteten meerdere atoomklokken hebben.
Meer achtergrond over de spreker via https://berthub.eu/articles/posts/mch-dna-and-gps-gnss-talks/
Q
We zullen dus een ander onwrikbaar eindpunt moeten hebben - een op ons DNA gebaseerde QR-code wellicht?
Mensen denken soms te kort door de bocht. Een vijver met een lotusbloem die steeds verdubbelt en zo een meer vult kan in 48 dagen het hele meer bedekken. Wanneer was het meer hiermeehalf gevuld? Niet na 24, maar na 47 dagen dus?
Wie heeft de oplossing voor het encryptie probleem?
Mensen denken soms te kort door de bocht. Een vijver met een lotusbloem die steeds verdubbelt en zo een meer vult kan in 48 dagen het hele meer bedekken. Wanneer was het meer hiermeehalf gevuld? Niet na 24, maar na 47 dagen dus?
Wie heeft de oplossing voor het encryptie probleem?
Door Anoniem: We zullen dus een ander onwrikbaar eindpunt moeten hebben - een op ons DNA gebaseerde QR-code wellicht?
Waarom denk je dat een "onwrikbaar eindpunt" zo nuttig of nodig is ?
Neem een mac adres, of een UUID als je een device-unieke property zoekt .
Of genereer een lang genoeg random getal . Ook uniek .
Maar begin eens met een coherent idee wat je daarmee wilt bereiken .
Dat was ook al een probleem bij Luntrus' handwaving dat je iets zou hebben aan een vermeend uniek/constante tijd-offset.
Mensen denken soms te kort door de bocht. Een vijver met een lotusbloem die steeds verdubbelt en zo een meer vult kan in 48 dagen het hele meer bedekken. Wanneer was het meer hiermeehalf gevuld? Niet na 24, maar na 47 dagen dus?
Ja, exponentieel groeit snel. en ? Het heeft er helemaal niks mee te maken . Ga graankorrels tellen op een schaakbord
Door Anoniem:
Waarom denk je dat een "onwrikbaar eindpunt" zo nuttig of nodig is ?
Neem een mac adres, of een UUID als je een device-unieke property zoekt .
Of genereer een lang genoeg random getal . Ook uniek .
Maar begin eens met een coherent idee wat je daarmee wilt bereiken .
Dat was ook al een probleem bij Luntrus' handwaving dat je iets zou hebben aan een vermeend uniek/constante tijd-offset.
[Anoniem nr. 3] Het zoeken naar een "onwrikbaar eindpunt" is de slang die zich in de eigen staart bijt.Door Anoniem: We zullen dus een ander onwrikbaar eindpunt moeten hebben - een op ons DNA gebaseerde QR-code wellicht?
Waarom denk je dat een "onwrikbaar eindpunt" zo nuttig of nodig is ?
Neem een mac adres, of een UUID als je een device-unieke property zoekt .
Of genereer een lang genoeg random getal . Ook uniek .
Maar begin eens met een coherent idee wat je daarmee wilt bereiken .
Dat was ook al een probleem bij Luntrus' handwaving dat je iets zou hebben aan een vermeend uniek/constante tijd-offset.
Je moet juist geen onwrikbare eindpunten hebben, en al beslist helemaal geen eindpunten, die aan de persoon gebonden zijn (obv biometrie bijvoorbeeld). Je moet iets flexibels, iets vloeiends creëren.
Het hele nut van encryptie komt in haar tegendeel te verkeren wanneer je de onwrikbaarheid gaat koppelen aan iets onwrikbaars in de betrokken personen, wanneer dat gekraakt wordt zijn ook de personen "gekraakt".
Het willen vastleggen van mensen op iets onwrikbaars van hen is des duivels, ook wel staat of macht genaamd.
Daar moet je ùit, je moet de ontwikkeling ombuigen naar iets waarover de persoon kan beschikken of niet, dus wat hij ook kan weggooien. Het vastleggen van mensen aan iets onwrikbaars leidt naar een digitale gevangenis.
Doe dat dan met flutter om te encrypten
Wellicht handig in het huidig herfst seizoen.
flutter_barcode_scanner: ^2.0.0 //for scanning QR
encrypt: ^5.0.0 //for AES encrption
qr_flutter: ^4.0.0 //to generate QR
url_launcher: ^6.0.3 //to launch the link in a browser
encrypt: ^5.0.0 //for AES encrption
qr_flutter: ^4.0.0 //to generate QR
url_launcher: ^6.0.3 //to launch the link in a browser
Wellicht handig in het huidig herfst seizoen.
Bij Crypto.js is er het probleem dat Math.random() onveilig is.
luntrus
luntrus
Toch ben ik heel blij met deze reacties. Zij helpen met het vinden van een juiste insteek.
Het gaat juist om die overwegingen, die belangrijk zijn.
Die zijn tevens van belang voor iedereen, die iets met beveiliging te maken heeft. Je moet er op gewezen worden om het te zien en als je het (in)ziet, begrijp je het ook.
Dank voor deze opmerkingen, de goedbedoelde 'draaien om de begripsoren' vergeet men nooit meer. Blij met een goede 'drill'.
Ik geloof in l'education permanente.
Goede en veilige ecryptie beveiliging zal in deze via BigTechno aangestuurde digitale wereld steeds belangrijker worden.
luntrus
.
Het gaat juist om die overwegingen, die belangrijk zijn.
Die zijn tevens van belang voor iedereen, die iets met beveiliging te maken heeft. Je moet er op gewezen worden om het te zien en als je het (in)ziet, begrijp je het ook.
Dank voor deze opmerkingen, de goedbedoelde 'draaien om de begripsoren' vergeet men nooit meer. Blij met een goede 'drill'.
Ik geloof in l'education permanente.
Goede en veilige ecryptie beveiliging zal in deze via BigTechno aangestuurde digitale wereld steeds belangrijker worden.
luntrus
.
Door Anoniem: Bij Crypto.js is er het probleem dat Math.random() onveilig is.
luntrus
luntrus
Nou, dan moet je die maar niet gebruiken als PRNG , toch ?
Het is tenminste netjes gedocumenteerd:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/random
Zie de Note:
https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues lijkt beter geschikt als je in javascript crypto-kwaliteit random getallen nodig hebt.
Door Anoniem: Bij Crypto.js is er het probleem dat Math.random() onveilig is.
luntrus
Waar slaat dit nou weer op?luntrus
Iedere programmeertaal die ik ken heeft een random()-functie in de standard library waarvan bekend is (en de documentatie waarschuwt ervoor!) dat die niet geschikt is voor cryptografie. Daarvoor zijn aparte libraries beschikbaar die wel cryptografisch bruikbare toevalsgetallen kunnen leveren. Da's bij JavaScript niet anders.
Dit is dus alleen maar een probleem als een programmeur zo naïef of incompetent is om niet de juiste functies aan te roepen. Wie dat doet maakt trouwens duidelijk geen documentatie te lezen, want bij Math.random() staat een duidelijk gemarkeerde waarschuwing dat het ongeschikt is voor cryptografie:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/random
Voor een adept van de search lores van FRAVIA geef je er met deze opmerking trouwens geen blijk van dat je ook de moeite doet om die zoekvaardigheden toe te passen. Dit is allemaal met simpele zoekopdrachten te vinden, namelijk.
Waarom plaats je zo'n totaal onzinnige en onjuiste opmerking, luntrus? Wat wil je ermee bereiken?
Het stond als algemene waarschuwing gegeven bij flutter.
Mijn ervaring is JS, retire.JS en SNYK. Website security, waar zit daar de juiste encryptie insteek?
Mijn ervaring is JS, retire.JS en SNYK. Website security, waar zit daar de juiste encryptie insteek?
Je zou het Ethernet-signaal kunnen meten, direct als het op de eerste switch binnenkomt. Afhankelijk van de gebruikte chispet + onderdelen is te bepalen welk merk. Dit doet de RWD ook bij testen van sjoemeldiesels, je kunt zien wie er extra op de CANbus zit (= signature niet bekend).
@anoniem van 16:55,
Dank voor je meedenken. Ik ga me nu verdiepen in de juiste manier om dit in script te vatten. Dank voor je reactie.
Alles wat hier gedeeld wordt is immers ten dienste van 'algemeen inzicht'.
De meeste zaken komen tot stand met vallen en opstaan. Wie bang is iets verkeerd te doen, heeft nog nooit iets bereikt.
luntrus
Dank voor je meedenken. Ik ga me nu verdiepen in de juiste manier om dit in script te vatten. Dank voor je reactie.
Alles wat hier gedeeld wordt is immers ten dienste van 'algemeen inzicht'.
De meeste zaken komen tot stand met vallen en opstaan. Wie bang is iets verkeerd te doen, heeft nog nooit iets bereikt.
luntrus
Door Anoniem: Je zou het Ethernet-signaal kunnen meten, direct als het op de eerste switch binnenkomt. Afhankelijk van de gebruikte chispet + onderdelen is te bepalen welk merk. Dit doet de RWD ook bij testen van sjoemeldiesels, je kunt zien wie er extra op de CANbus zit (= signature niet bekend).
En als ik met mijn laptop gebruik maak van een ander netwerk wijkt het signaal af. Als ik de nic vervang heb ik een afwijking. Als ik een nieuwe videokaart gebruik klopt het niet meer. Als ik geheugen vervang of bijsteek… nou ja, je begrijpt het inmiddels wel denk ik.
Naast compressors, obfuscators en minifiers is er niet veel voor JavaScript.
Encryptie gebaseerd op enige 'constante' is dus a priori een non-idee. Er werden vroeger in de tijden van het oude Romeook tien spionnen weggestuurd elk met maar een stukje van de geheime boodschap.
luntrus
luntrus
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?