Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Dataset onthult RSA-private keys
13-08-2018, 11:39 door [Account Verwijderd], 19 reacties
Wie weet hier meer over?
Volgens de website Tweakers zouden onderzoekers van Kudelski Security er in geslaagd zijn door tweehonderdduizend RSA-private keys te achterhalen d.m.v. het analyseren van een dataset van 340 miljoen public keys.
Het hele verhaal staat hier te lezen:
https://tweakers.net/nieuws/141993/onderzoekers-vinden-ruim-200000-rsa-privesleutels-door-analyse-grote-dataset.html
Ik vind tot nu toe geen bericht op andere websites hierover m.b.t. deze recente fondst, en Tweakers geeft in het artikel geen link waar ze dit verhaal vandaan hebben gehaald. Mijn eigen public keys heb ik wel getest om te zien of deze kwetsbaar zijn voor de z.g. Roca-aanval. Daar is in ieder geval niets van gebleken.
De website om je public keys te testen inzake de Roca-aanval vind je trouwens hier: https://keychest.net/roca#/
Wie eventueel een link kan doorgeven waar het originele verhaal staat, dan heel graag een reactie.
Volgens de website Tweakers zouden onderzoekers van Kudelski Security er in geslaagd zijn door tweehonderdduizend RSA-private keys te achterhalen d.m.v. het analyseren van een dataset van 340 miljoen public keys.
Het hele verhaal staat hier te lezen:
https://tweakers.net/nieuws/141993/onderzoekers-vinden-ruim-200000-rsa-privesleutels-door-analyse-grote-dataset.html
Ik vind tot nu toe geen bericht op andere websites hierover m.b.t. deze recente fondst, en Tweakers geeft in het artikel geen link waar ze dit verhaal vandaan hebben gehaald. Mijn eigen public keys heb ik wel getest om te zien of deze kwetsbaar zijn voor de z.g. Roca-aanval. Daar is in ieder geval niets van gebleken.
De website om je public keys te testen inzake de Roca-aanval vind je trouwens hier: https://keychest.net/roca#/
Wie eventueel een link kan doorgeven waar het originele verhaal staat, dan heel graag een reactie.
Reacties (19)
Door Fidelis: Wie weet hier meer over?
Volgens de website Tweakers zouden onderzoekers van Kudelski Security er in geslaagd zijn door tweehonderdduizend RSA-private keys te achterhalen d.m.v. het analyseren van een dataset van 340 miljoen public keys.
Het hele verhaal staat hier te lezen:
https://tweakers.net/nieuws/141993/onderzoekers-vinden-ruim-200000-rsa-privesleutels-door-analyse-grote-dataset.html
Ik vind tot nu toe geen bericht op andere websites hierover m.b.t. deze recente fondst, en Tweakers geeft in het artikel geen link waar ze dit verhaal vandaan hebben gehaald. Mijn eigen public keys heb ik wel getest om te zien of deze kwetsbaar zijn voor de z.g. Roca-aanval. Daar is in ieder geval niets van gebleken.
De website om je public keys te testen inzake de Roca-aanval vind je trouwens hier: https://keychest.net/roca#/
Wie eventueel een link kan doorgeven waar het originele verhaal staat, dan heel graag een reactie.
Volgens de website Tweakers zouden onderzoekers van Kudelski Security er in geslaagd zijn door tweehonderdduizend RSA-private keys te achterhalen d.m.v. het analyseren van een dataset van 340 miljoen public keys.
Het hele verhaal staat hier te lezen:
https://tweakers.net/nieuws/141993/onderzoekers-vinden-ruim-200000-rsa-privesleutels-door-analyse-grote-dataset.html
Ik vind tot nu toe geen bericht op andere websites hierover m.b.t. deze recente fondst, en Tweakers geeft in het artikel geen link waar ze dit verhaal vandaan hebben gehaald. Mijn eigen public keys heb ik wel getest om te zien of deze kwetsbaar zijn voor de z.g. Roca-aanval. Daar is in ieder geval niets van gebleken.
De website om je public keys te testen inzake de Roca-aanval vind je trouwens hier: https://keychest.net/roca#/
Wie eventueel een link kan doorgeven waar het originele verhaal staat, dan heel graag een reactie.
Zo te zien een Blackhat /Defcon presentatie .
https://modernciso.com/2018/07/30/black-hat-usa-2018-presentation-picks/ , zoek naar Reaping and Breaking Keys at Scale: When Crypto Meets Big Data
(site media.defcon.org is momenteel voor mij niet bereikbaar, daar staat de presentatie)
batch GCD : https://facthacks.cr.yp.to/batchgcd.html
Als ik het goed begrijp gaat het hier om keys die een factor gemeen hebben met een andere key.
N1 = P* Q
N2 = P *W
Als dat het geval is kan GCD zo'n gemeenschappelijke factor heel veel makkelijker vinden dan N1 en N2 eerst te ontbinden.
En 'batch GCD' is blijkbaar een manier om dat efficient te doen tussen veel keyparen.
Ik denk dat zo'n probleem alleen voorkomt als je een slechte key-generatie hebt , en een hele serie sleutels moet genereren en iemand dacht 'slim' te zijn door geen twee, maar slechts één nieuw priemgetal per sleutel te zoeken .
zie ook https://cryptosense.com/blog/batch-gcding-github-ssh-keys
Door Anoniem:
Ik denk dat zo'n probleem alleen voorkomt als je een slechte key-generatie hebt , en een hele serie sleutels moet genereren en iemand dacht 'slim' te zijn door geen twee, maar slechts één nieuw priemgetal per sleutel te zoeken .
Ik denk dat zo'n probleem alleen voorkomt als je een slechte key-generatie hebt , en een hele serie sleutels moet genereren en iemand dacht 'slim' te zijn door geen twee, maar slechts één nieuw priemgetal per sleutel te zoeken .
Daaruit blijkt maar weer eens wat het grote belang van niet alleen een 'snelle', maar eerder van een echte true-RNG.
Introduction to Randomness and Random Numbers
by Dr Mads Haahr
https://www.random.org/randomness/
Big data , big leaks. Een wijze hacker (mkultradead nu en kan niets meer presteren) zei het al jaren geleden.
Door Anoniem:
Zo te zien een Blackhat /Defcon presentatie .
https://modernciso.com/2018/07/30/black-hat-usa-2018-presentation-picks/ , zoek naar Reaping and Breaking Keys at Scale: When Crypto Meets Big Data
(site media.defcon.org is momenteel voor mij niet bereikbaar, daar staat de presentatie)
batch GCD : https://facthacks.cr.yp.to/batchgcd.html
Als ik het goed begrijp gaat het hier om keys die een factor gemeen hebben met een andere key.
N1 = P* Q
N2 = P *W
Als dat het geval is kan GCD zo'n gemeenschappelijke factor heel veel makkelijker vinden dan N1 en N2 eerst te ontbinden.
En 'batch GCD' is blijkbaar een manier om dat efficient te doen tussen veel keyparen.
Ik denk dat zo'n probleem alleen voorkomt als je een slechte key-generatie hebt , en een hele serie sleutels moet genereren en iemand dacht 'slim' te zijn door geen twee, maar slechts één nieuw priemgetal per sleutel te zoeken .
zie ook https://cryptosense.com/blog/batch-gcding-github-ssh-keys
Door Fidelis: Wie weet hier meer over?
Volgens de website Tweakers zouden onderzoekers van Kudelski Security er in geslaagd zijn door tweehonderdduizend RSA-private keys te achterhalen d.m.v. het analyseren van een dataset van 340 miljoen public keys.
Het hele verhaal staat hier te lezen:
https://tweakers.net/nieuws/141993/onderzoekers-vinden-ruim-200000-rsa-privesleutels-door-analyse-grote-dataset.html
Ik vind tot nu toe geen bericht op andere websites hierover m.b.t. deze recente fondst, en Tweakers geeft in het artikel geen link waar ze dit verhaal vandaan hebben gehaald. Mijn eigen public keys heb ik wel getest om te zien of deze kwetsbaar zijn voor de z.g. Roca-aanval. Daar is in ieder geval niets van gebleken.
De website om je public keys te testen inzake de Roca-aanval vind je trouwens hier: https://keychest.net/roca#/
Wie eventueel een link kan doorgeven waar het originele verhaal staat, dan heel graag een reactie.
Volgens de website Tweakers zouden onderzoekers van Kudelski Security er in geslaagd zijn door tweehonderdduizend RSA-private keys te achterhalen d.m.v. het analyseren van een dataset van 340 miljoen public keys.
Het hele verhaal staat hier te lezen:
https://tweakers.net/nieuws/141993/onderzoekers-vinden-ruim-200000-rsa-privesleutels-door-analyse-grote-dataset.html
Ik vind tot nu toe geen bericht op andere websites hierover m.b.t. deze recente fondst, en Tweakers geeft in het artikel geen link waar ze dit verhaal vandaan hebben gehaald. Mijn eigen public keys heb ik wel getest om te zien of deze kwetsbaar zijn voor de z.g. Roca-aanval. Daar is in ieder geval niets van gebleken.
De website om je public keys te testen inzake de Roca-aanval vind je trouwens hier: https://keychest.net/roca#/
Wie eventueel een link kan doorgeven waar het originele verhaal staat, dan heel graag een reactie.
Zo te zien een Blackhat /Defcon presentatie .
https://modernciso.com/2018/07/30/black-hat-usa-2018-presentation-picks/ , zoek naar Reaping and Breaking Keys at Scale: When Crypto Meets Big Data
(site media.defcon.org is momenteel voor mij niet bereikbaar, daar staat de presentatie)
batch GCD : https://facthacks.cr.yp.to/batchgcd.html
Als ik het goed begrijp gaat het hier om keys die een factor gemeen hebben met een andere key.
N1 = P* Q
N2 = P *W
Als dat het geval is kan GCD zo'n gemeenschappelijke factor heel veel makkelijker vinden dan N1 en N2 eerst te ontbinden.
En 'batch GCD' is blijkbaar een manier om dat efficient te doen tussen veel keyparen.
Ik denk dat zo'n probleem alleen voorkomt als je een slechte key-generatie hebt , en een hele serie sleutels moet genereren en iemand dacht 'slim' te zijn door geen twee, maar slechts één nieuw priemgetal per sleutel te zoeken .
zie ook https://cryptosense.com/blog/batch-gcding-github-ssh-keys
aanvullend:
site doet het weer:
https://media.defcon.org/DEF%20CON%2026/DEF%20CON%2026%20presentations/DEFCON-26-Nils-Amiet-and-Yonal-Romailler-Reaping-and-breaking-keys-at-scale-when-crypto-meets-big-data.pdf
Heel korte recap :
343M keys, >200K rsa keys met probleem gevonden , vrijwel allemaal in X.509 certs, en vrijwel allemaal op (consumenten) routers .
Leuke research, m.i. niks om van wakker te liggen.
Door Anoniem: Kan ik ook ergens checken of mijn private keys gelekt zijn?
Welja, ik zal wel even een testserver opzetten.Als jij dan je private key test, roep ik:
Neh neh neh-neh neh ik je private keyhie, ik heb je private keyhie.
Door Anoniem:
Daaruit blijkt maar weer eens wat het grote belang van niet alleen een 'snelle', maar eerder van een echte true-RNG.
Door Anoniem:
Ik denk dat zo'n probleem alleen voorkomt als je een slechte key-generatie hebt , en een hele serie sleutels moet genereren en iemand dacht 'slim' te zijn door geen twee, maar slechts één nieuw priemgetal per sleutel te zoeken .
Ik denk dat zo'n probleem alleen voorkomt als je een slechte key-generatie hebt , en een hele serie sleutels moet genereren en iemand dacht 'slim' te zijn door geen twee, maar slechts één nieuw priemgetal per sleutel te zoeken .
Daaruit blijkt maar weer eens wat het grote belang van niet alleen een 'snelle', maar eerder van een echte true-RNG.
Nou nee. Er is helemaal niet gezegd dat de priemgetallen afkomstig waren van verkeerde RNGs. Er waren alleen priemgetallen meerdere malen gebruikt - ze kunnen/konden nog steeds afkomstig zijn van true RNGs.
In elk geval is het laatste wat je moet doen je crypto-random getallen van de een of andere website downloaden.
Waar de site (iig op de front pagina) te weinig over zegt is over de uitdaging(en) om de bron van randomness correct te samplen, en eventuele correlaties als gevolg van samplen te vermijden.
Door Anoniem:
Zo te zien een Blackhat /Defcon presentatie .
https://modernciso.com/2018/07/30/black-hat-usa-2018-presentation-picks/ , zoek naar Reaping and Breaking Keys at Scale: When Crypto Meets Big Data
(site media.defcon.org is momenteel voor mij niet bereikbaar, daar staat de presentatie)
batch GCD : https://facthacks.cr.yp.to/batchgcd.html
Als ik het goed begrijp gaat het hier om keys die een factor gemeen hebben met een andere key.
N1 = P* Q
N2 = P *W
Als dat het geval is kan GCD zo'n gemeenschappelijke factor heel veel makkelijker vinden dan N1 en N2 eerst te ontbinden.
En 'batch GCD' is blijkbaar een manier om dat efficient te doen tussen veel keyparen.
Ik denk dat zo'n probleem alleen voorkomt als je een slechte key-generatie hebt , en een hele serie sleutels moet genereren en iemand dacht 'slim' te zijn door geen twee, maar slechts één nieuw priemgetal per sleutel te zoeken .
zie ook https://cryptosense.com/blog/batch-gcding-github-ssh-keys
Dank voor de informatie. Ik zal het nu verder uitzoeken.Door Fidelis: Wie weet hier meer over?
Volgens de website Tweakers zouden onderzoekers van Kudelski Security er in geslaagd zijn door tweehonderdduizend RSA-private keys te achterhalen d.m.v. het analyseren van een dataset van 340 miljoen public keys.
Het hele verhaal staat hier te lezen:
https://tweakers.net/nieuws/141993/onderzoekers-vinden-ruim-200000-rsa-privesleutels-door-analyse-grote-dataset.html
Ik vind tot nu toe geen bericht op andere websites hierover m.b.t. deze recente fondst, en Tweakers geeft in het artikel geen link waar ze dit verhaal vandaan hebben gehaald. Mijn eigen public keys heb ik wel getest om te zien of deze kwetsbaar zijn voor de z.g. Roca-aanval. Daar is in ieder geval niets van gebleken.
De website om je public keys te testen inzake de Roca-aanval vind je trouwens hier: https://keychest.net/roca#/
Wie eventueel een link kan doorgeven waar het originele verhaal staat, dan heel graag een reactie.
Volgens de website Tweakers zouden onderzoekers van Kudelski Security er in geslaagd zijn door tweehonderdduizend RSA-private keys te achterhalen d.m.v. het analyseren van een dataset van 340 miljoen public keys.
Het hele verhaal staat hier te lezen:
https://tweakers.net/nieuws/141993/onderzoekers-vinden-ruim-200000-rsa-privesleutels-door-analyse-grote-dataset.html
Ik vind tot nu toe geen bericht op andere websites hierover m.b.t. deze recente fondst, en Tweakers geeft in het artikel geen link waar ze dit verhaal vandaan hebben gehaald. Mijn eigen public keys heb ik wel getest om te zien of deze kwetsbaar zijn voor de z.g. Roca-aanval. Daar is in ieder geval niets van gebleken.
De website om je public keys te testen inzake de Roca-aanval vind je trouwens hier: https://keychest.net/roca#/
Wie eventueel een link kan doorgeven waar het originele verhaal staat, dan heel graag een reactie.
Zo te zien een Blackhat /Defcon presentatie .
https://modernciso.com/2018/07/30/black-hat-usa-2018-presentation-picks/ , zoek naar Reaping and Breaking Keys at Scale: When Crypto Meets Big Data
(site media.defcon.org is momenteel voor mij niet bereikbaar, daar staat de presentatie)
batch GCD : https://facthacks.cr.yp.to/batchgcd.html
Als ik het goed begrijp gaat het hier om keys die een factor gemeen hebben met een andere key.
N1 = P* Q
N2 = P *W
Als dat het geval is kan GCD zo'n gemeenschappelijke factor heel veel makkelijker vinden dan N1 en N2 eerst te ontbinden.
En 'batch GCD' is blijkbaar een manier om dat efficient te doen tussen veel keyparen.
Ik denk dat zo'n probleem alleen voorkomt als je een slechte key-generatie hebt , en een hele serie sleutels moet genereren en iemand dacht 'slim' te zijn door geen twee, maar slechts één nieuw priemgetal per sleutel te zoeken .
zie ook https://cryptosense.com/blog/batch-gcding-github-ssh-keys
Door Anoniem: Big data , big leaks. Een wijze hacker (mkultradead nu en kan niets meer presteren) zei het al jaren geleden.
Dat was mij ook al bekend en nieuw is de methode van Kudelski Security ook niet.Ik vind het nog steeds schokkend dat een onderzoek (als deze) RSA-private keys kan onthullen.
Door Anoniem: Kan ik ook ergens checken of mijn private keys gelekt zijn?
Dan zou je zelf moeten nagaan of jouw keys dezelfde factor delen met andere keys. Zoiets kan je nagaan via Batch gcd. https://facthacks.cr.yp.to/batchgcd.htmlVerder is er nog een interessante opmerking op de site van Tweakers te lezen:
De ROCA-test, zoals die is genoemd op Tweakers, is vooral interessant als je sleutels hebt gegenereerd met bepaalde INFINEON chips. Via deze ROCA-test kom je erachter of je publieke sleutel tot de categorie "kwetsbare" sleutels behoort, dus dat via je publieke sleutel, je privé sleutels kunnen worden onthuld. Mocht dat inderdaad het geval zijn, dan lijkt het mij zeer verstandig deze keys ogenblikkelijk in te trekken (denk maar bijvoorbeeld aan het gebruik van PGP) en een nieuw paar sleutels, op een nieuw en gepatcht systeem te genereren.
De ROCA-test staat onderaan deze pagina:
https://keychest.net/roca#/
De ROCA-test, zoals die is genoemd op Tweakers, is vooral interessant als je sleutels hebt gegenereerd met bepaalde INFINEON chips. Via deze ROCA-test kom je erachter of je publieke sleutel tot de categorie "kwetsbare" sleutels behoort, dus dat via je publieke sleutel, je privé sleutels kunnen worden onthuld. Mocht dat inderdaad het geval zijn, dan lijkt het mij zeer verstandig deze keys ogenblikkelijk in te trekken (denk maar bijvoorbeeld aan het gebruik van PGP) en een nieuw paar sleutels, op een nieuw en gepatcht systeem te genereren.
De ROCA-test staat onderaan deze pagina:
https://keychest.net/roca#/
Door Fidelis:
Door Anoniem: Kan ik ook ergens checken of mijn private keys gelekt zijn?
Dan zou je zelf moeten nagaan of jouw keys dezelfde factor delen met andere keys. Zoiets kan je nagaan via Batch gcd. https://facthacks.cr.yp.to/batchgcd.htmlNu ja, je kunt het nagaan als je die hele batch andere sleutels hebt waarin je een sleutel met gedeelde priem zoekt, een behoorlijk stevige set van servers e.d.
Als je die presentatie bekijkt is het ( zo te zien) vooral een probleem van een serie consumenten netwerk devices
Door Anoniem: Nou nee. Er is helemaal niet gezegd dat de priemgetallen afkomstig waren van verkeerde RNGs. Er waren alleen priemgetallen meerdere malen gebruikt - ze kunnen/konden nog steeds afkomstig zijn van true RNGs.
Dat is inmiddels duidelijk.
In elk geval is het laatste wat je moet doen je crypto-random getallen van de een of andere website downloaden.
Gaat ook niet gebeuren.
Waar de site (iig op de front pagina) te weinig over zegt is over de uitdaging(en) om de bron van randomness correct te samplen, en eventuele correlaties als gevolg van samplen te vermijden.
Dat is aan de afdeling elektrotechniek en de statistici om dat te bewijzen.
Door Anoniem:
wat je moet doen je crypto-random getallen van de een of andere website downloaden.
Gaat ook niet gebeuren.
wat je moet doen je crypto-random getallen van de een of andere website downloaden.
Gaat ook niet gebeuren.
Ik hoop het. Anoniem 14:39 gaf alleen site en het advies om een tRNG te gebruiken - zonder deze tip.
De site zelf loopt ook niet over van de waarschuwingen dat je random getallen van een publieke site halen ze ongeschikt maakt voor security zaken .
Hoewel ik het (na een tijdje zoeken ) wel vond https://www.random.org/faq/#Q2.4
De testimonials die er staan suggereren dat een hoop mensen daar niet over nadenken.
Waar de site (iig op de front pagina) te weinig over zegt is over de uitdaging(en) om de bron van randomness correct te samplen, en eventuele correlaties als gevolg van samplen te vermijden.
Dat is aan de afdeling elektrotechniek en de statistici om dat te bewijzen.
Dat zijn inderdaad de relevante vakgebieden - maar als je alleen maar de quantum/thermisch of anderszins true-random van de bron bespreekt zonder het probleem van het 'bewaren' van die bron-entropie tot en met de output als serie van bitten - vind ik dat een omissie en daalt mijn waardering voor de auteur een paar treden.
RSA is in 2013 al eens middels side channel technieken gekraakt. Voor mij reden om geen RSA meer in te zetten op servers.
En des te meer reden om zo snel mogelijk over te gaan op TLS 1.3
https://www.extremetech.com/extreme/173108-researchers-crack-the-worlds-toughest-encryption-by-listening-to-the-tiny-sounds-made-by-your-computers-cpu
en
http://www.tau.ac.il/~tromer/papers/acoustic-20131218.pdf
En des te meer reden om zo snel mogelijk over te gaan op TLS 1.3
https://www.extremetech.com/extreme/173108-researchers-crack-the-worlds-toughest-encryption-by-listening-to-the-tiny-sounds-made-by-your-computers-cpu
en
http://www.tau.ac.il/~tromer/papers/acoustic-20131218.pdf
Door Anoniem:Hoewel ik het (na een tijdje zoeken ) wel vond https://www.random.org/faq/#Q2.4
[...] anyone genuinely concerned with security should not trust anyone else (including RANDOM.ORG) to generate their cryptographic keys.
Gerust gesteld?
De testimonials die er staan suggereren dat een hoop mensen daar niet over nadenken.
Dat is ook niet echt nodig als men voor een bejaardentehuis een Bingo avond wil organiseren. Voor alles wat meer serieus is, wordt true-RNG hardware gemaakt die onder de loupe gaat bij de afdeling elektrotechniek en onafhankelijke statistici.
Door Anoniem:
[...] anyone genuinely concerned with security should not trust anyone else (including RANDOM.ORG) to generate their cryptographic keys.
Gerust gesteld?
Door Anoniem:Hoewel ik het (na een tijdje zoeken ) wel vond https://www.random.org/faq/#Q2.4
[...] anyone genuinely concerned with security should not trust anyone else (including RANDOM.ORG) to generate their cryptographic keys.
Gerust gesteld?
Enorm - ik had alleen maar de URL gevonden waar de quote staat, maar die quote lezen was niet van gekomen, dus goed dat je 't even ge cut/paste hebt . (WTF? )
De testimonials die er staan suggereren dat een hoop mensen daar niet over nadenken.
Dat is ook niet echt nodig als men voor een bejaardentehuis een Bingo avond wil organiseren. Voor alles wat meer serieus is, wordt true-RNG hardware gemaakt die onder de loupe gaat bij de afdeling elektrotechniek en onafhankelijke statistici.
Ik hoop het maar - het aantal mensen dat zich realiseert dat dat nodig is wanneer het om serieuze zaken gaat is zorgwekkend klein .
Door Anoniem:
https://www.extremetech.com/extreme/173108-researchers-crack-the-worlds-toughest-encryption-by-listening-to-the-tiny-sounds-made-by-your-computers-cpu
https://www.extremetech.com/extreme/173108-researchers-crack-the-worlds-toughest-encryption-by-listening-to-the-tiny-sounds-made-by-your-computers-cpu
" keep your laptop in a sound-tight box, or never let anyone near your computer when you’re decrypting data — or you need to use a “sufficiently strong wide-band noise source.” Something like a swooping, large-orchestra classical concerto would probably do it. "
Laat ik nu net een liefhebber van klassieke muziek wezen. En een audio CD in de lade leggen is heel eenvoudig. Dan gaat het heel moeilijk worden om een parabolische richtmicofoon toe te passen. Alleen al de mechanische ruis.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
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?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
