Siirrettävän datan salaus on ratkaistu ongelma — kunnes vastustajalla on kvanttitietokone. Symmetriset salakirjoitukset, kuten AES-256, selviävät kvanttisesta uhasta. RSA ja elliptisen käyrän avainvaihto eivät: Shorin algoritmi, joka toimii riittävän suurella vikasietoisella kvanttiprosessorilla, tekijälöi RSA-avaimet ja ratkaisee diskreetin logaritmin ongelman polynomisessa ajassa, jolloin klassisella julkisen avaimen kryptografialla neuvoteltu istuntoavain on taannehtivasti luettavissa. Käytännön uhka ei ole tuleva hyökkäys vaan nykyinen: vastustajat sieppaavat ja tallentavat salattua puolustusliikennettä tänään, vedoten siihen, että kvanttilaitteisto lopulta antaa heidän purkaa sen. Kerää-nyt-pura-myöhemmin -hyökkäystä vastaan ei ole puolustusta paitsi kvanttijälkeinen salaus, jota sovelletaan alkuperäisessä avainvaihdossa.
Corvus.Quantum on kvanttikestävä tietovirtausalusta, joka on rakennettu luokiteltuihin puolustusviestintöihin. Se yhdistää Apache Kafkan hajautetun tietovirran rungon hilapohjaiseen kvanttijälkeiseen salaukseen — erityisesti NTRUEncryptiin ja CRYSTALS-Kyberiin — ja kerrostaa täyden Zero Trust -arkkitehtuurin koko topologian päälle. Tässä artikkelissa analysoidaan, kuinka nämä komponentit ovat vuorovaikutuksessa keskenään, kuinka kaksoisavainjakelumekhanismi toimii ja kuinka puolustuksen insinööritiimi integroi Python SDK:n olemassa olevaan tietovirtaputkeen.
Miksi hilapohjainen salaus
Kvanttijälkeinen salaus kattaa useita algoritmiryhmiä: hilapohjaiset, hajautusfunktioperusteiset, koodiperusteiset ja isogeniaperusteiiset. Corvus.Quantum käyttää hilapohjaisia algoritmeja, koska ne tarjoavat parhaan suorituskyky-turvallisuussuhteen suuriläpimenoisia tietovirtauskuormia varten. Taustalla olevalla vaikea ongelmalla — lyhimmän vektorin ongelmalla (SVP) ja virheellä oppimisen ongelmalla (LWE) — ei ole tunnettua polynomisessa ajassa toimivaa kvanttialgoritmia. NIST saattoi kvanttijälkeisen standardointiprosessinsa päätökseen vuonna 2024 valitsemalla CRYSTALS-Kyberin (nyt standardoitu ML-KEM-nimellä FIPS 203:n alla) ensisijaiseksi avainkapselointimekanismiksi. NTRUEncrypt, pitkäaikaisempi hilapohjainen järjestelmä, säilytetään toissijaisena algoritmina avainkapselointiin tilanteissa, jotka vaativat FIPS 203:n vaihtoehtoja.
Avainkapselointiprosessi Corvus.Quantumissa toimii seuraavasti: tuottajasolmu luo lyhytikäisen ML-KEM-avainparin istuntoa kohden. Se lähettää julkisen avaimen (kapselointiavaimen) avainten hallintapalvelimelle QKD:llä suojatun tai mTLS:llä suojatun kanavan kautta. Palvelin kapseloi symmetrisen istunnon siemenen julkisella avaimella ja palauttaa salakirjoituksen. Molemmat osapuolet johtavat identtisen AES-256-istuntoavaimen siemenestä käyttäen HKDF:ää. Tämä istuntoavain salaa Kafka-viestin hyötykuorman — klassinen Diffie-Hellman tai RSA ei ole mukana missään vaiheessa avainneuvottelussa.
Keskeinen havainto: CRYSTALS-Kyber-avainkapselointi 128-bitin kvanttiturvatasolla (Kyber-768) lisää noin 1,1 kt:n ylikuorman istunnon muodostamista kohden ja valmistuu alle millisekunnissa tavallisella palvelinlaitteistolla. Tietovirtauskuormille, joissa istunnot kestävät minuutteja tai tunteja, tämä ylikuorma on merkityksetön. Pullonkaula kvanttiturvallisessa avainvaihdossa ei ole algoritmin suorituskyky — se on avainten hallintainfrastruktuuri ja verkon viive avainpalvelimeen.
Zero Trust sovellettuna tietovirtaviestintään
Kafka-klusteri ilman pääsynhallintaa on tasainen lähetysväline: mikä tahansa solmu, joka voi tavoittaa välittäjän, voi tuottaa tai kuluttaa mitä tahansa aihetta. Zero Trust poistaa tämän implisiittisen luottamusoletuksen vaatimalla jatkuvaa entiteettien todentamista jokaisessa kohdassa tietovirtauksen topologiassa — tuottajat, kuluttajat, välittäjät ja avainten hallintapalvelin osallistuvat kaikki keskinäiseen todennus- ja valtuutusketjuun.
Zero Trust -ohjaustaso Corvus.Quantumissa noudattaa NIST SP 800-207 -mallia kolmella komponentilla. Käytäntömoottori arvioi jokaisen käyttöpyynnön — tuottaja pyytää kirjoittamaan aiheeseen, kuluttaja pyytää tilaamaan, välittäjä pyytää avainta avainten hallintapalvelimelta — käytäntöjoukkoa vastaan, joka koodaa luokittelumerkinnät, organisaatioyksikön jäsenyyden ja kellonaikarajoitteet. Käytäntöhallinta kääntää käytäntöpäätökset lyhytikäisiksi tunnistetiedoiksi: Kafka ACL -myönnöiksi, avainten käyttötokeneiksi, joilla on rajoitettu TTL, ja mTLS-varmenteiksi, joihin on upotettu valtuutusvaatimukset. Käytännön täytäntöönpanopiste sijaitsee Kafka-välittäjän ja SDK-asiakkaan sisällä — se validoi jokaisen saapuvan yhteyden esitettyä tunnistetta vastaan ja hylkää yhteydet, joilla on vanhentuneita tai käytäntöepäsuhtaisia tunnistetietoja.
Mikään topologian solmu ei luota toiseen verkon sijainnin perusteella. Tuottajasolmu, joka on samassa konesalissa kuin välittäjä, esittää mTLS-varmenteensa jokaisessa yhteydessä; välittäjä validoi varmennusketjun, poimii valtuutusvaatimukset ja tarkistaa ne käytäntömoottoria vastaan ennen minkään tuottamispyynnön hyväksymistä. Vaarantunut välittäjä ei voi esiintyä avainten hallintapalvelimena, koska avainpalvelin validoi välittäjän varmenteen itsenäisesti. Tietovirtasolmujen välinen itä-länsi-luottamus on nolla — jokaisen solmun käyttöoikeus on rajattu täsmälleen niihin aiheisiin ja avaintunnisteisiin, joihin se on nimenomaisesti valtuutettu.
Keskeinen havainto: Zero Trust tietovirtaarkkitehtuureissa sulkee tietyn hyökkäysvektorin, jonka perimetrisuojaus ohittaa: vaarantunut kuluttajasolmu. Perimetrisuojatussa Kafka-klusterissa vaarantunut solmu, joka on jo verkon sisällä, voi tilata minkä tahansa aiheen, johon se voi reitittää. Corvus.Quantumin Zero Trust -mallissa vaarantuneen solmun varmennus peruutetaan käytäntömoottorilla, ja kaikki kyseisen varmenteen välittäjäpuolen ACL:t mitätöidään välimuistiin tallennetun käytäntöpäätöksen TTL:n kuluessa — tyypillisesti alle 60 sekunnissa. Hyökkääjä menettää tietovirtauksen ennen kuin hän voi suodattaa koko istunnon datan.
Apache Kafka -topologia: paikallinen vs Azure Event Hubs
Corvus.Quantum tukee kahta välittäjämääritystä. Paikallisessa käyttöönotossa Apache Kafka toimii operaattorin fyysisessä tilassa — vahvistetussa palvelinhuoneessa, taktisessa operaatiokeskuksessa tai ilmarakoverkossa olevassa luokitellussa verkossa. Kaikki välittäjäsolmut, ZooKeeper (tai KRaft) -koordinaattorit ja avainten hallintapalvelin toimivat tilan rajojen sisällä. Solmujen välinen verkkoliikenne kulkee fyysisesti hallitun median kautta. Tämä on konfiguraatio, jota käytetään aktiivisissa Ukrainan taistelualueen käyttöönotoissa, joissa luokiteltuja ääni- ja videovirtoja reititetään kiistanalaisen alueen kautta.
Azure Event Hubs -käyttöönotossa tietovirtauksen runko on Azure Event Hubs -hallintapalvelu, joka tarjoaa Kafka-yhteensopivan protokollapinnan. SDK:n välittäjäabstraktio tarkoittaa, että asiakaskoodi on identtinen molemmissa konfiguraatioissa — vain bootstrap-palvelimen osoite ja todennusparametrit eroavat. Azure Event Hubs Government Community Cloud (GCC High) -vuokraajassa tarjoaa FedRAMP High -vaatimustenmukaisuuden, mikä tekee siitä toteuttamiskelpoisen yhdysvaltalaisille liittovaltion puolustusprojekteille. Tässä konfiguraatiossa Corvus.Quantumin kvanttijälkeinen salaus varmistaa, että vaikka Azuren TLS-kerros vaarantuisi, sieppattu salakirjoitus pysyisi läpinäkymättömänä ilman Corvus-avainten hallintapalvelimen hallussa olevia hilapohjaisia istuntoavaimia.
Valinta kahden topologian välillä perustuu yhteys- ja vaatimustenmukaisuusvaatimuksiin eikä turvallisuuteen — salaus- ja Zero Trust -kerrokset tarjoavat vastaavan suojan molemmissa konfiguraatioissa. Organisaatiot, jotka eivät voi hyväksyä mitään pilvipalveluriippuvuutta herkimmille kuormilleen, käyttävät paikallista asennusta. Organisaatiot, jotka pyörittävät luokiteltuja mutta ei-ilmaraollisia kuormia hallitun pilven infrastruktuurilla, käyttävät Event Hubsia operatiivisen kuorman vähentämiseksi.
Kaksoisavainjakelu: QKD ja fyysisesti kloonaamattomat funktiot
Corvus.Quantumin istuntoavaimia ei johdeta yhdestä lähteestä. Alusta käyttää kahta toisiaan täydentävää mekanismia, ja lopullinen istuntoavain on molempien yhdistelmä — joten jommankumman kanavan vaarantaminen ei vaaranna istuntoavainta.
Kvanttinen avainjakelu (QKD) käyttää kvanttisia optisia kanavia — tyypillisesti polarisoituja fotoneja, jotka lähetetään omistetuilla kuiduilla — symmetrisen avainmateriaalin vaihtamiseen informaatioteorian mukaisella turvallisuudella. Mikä tahansa yritys siepata tai mitata kvanttikanava häiritsee fotonitiloja ja aiheuttaa havaittavia virheitä; protokolla keskeyttää ja neuvottelee uudelleen, kun virheaste ylittää kynnyksen. QKD on siksi ainoa avainvaihtomekanismi, jolla on fyysinen tunnistusmekanismi välimieshyökkäykselle. Sen rajoitus on infrastruktuuri: QKD vaatii omistettuja kuituja ja on tällä hetkellä rajoittunut piste-piste-yhteyksiin enintään muutamaan sataan kilometriin ilman kvanttirepeatereitä. Corvus.Quantum-käyttöönotoissa, joissa on QKD-yhteensopiva infrastruktuuri, QKD tarjoaa ensisijaisen avainentropia-panoksen.
Fyysisesti kloonaamattomat funktiot (PUF) johtavat salausavainmateriaalin piilaitteen luontaisista fyysisistä valmistusvaihteluista — transistorien kynnyskertojen, johtimien viiveiden ja muistisolun käyttäytymisen vaihteluista, jotka ovat ainutlaatuisia kullekin laitteelle eivätkä ole kloonattavissa tai purettavissa ohjelmistoilla. PUF-yhteensopiva laitteistoturvamodeeli esittää haaste-vastaus-rajapinnan: annetulla haastesyötteellä laite tuottaa fyysisesti määritellyn vastauksen, joka on vakaa virransyklien välillä mutta ainutlaatuinen kyseiselle fyysiselle laitteelle. Corvus.Quantum käyttää PUF-vastauksia toisena avainentropia-lähteenä, XOR:attuna QKD:stä johdetun materiaalin kanssa (tai siellä missä QKD ei ole saatavilla, CRYSTALS-Kyberistä johdetun siemenen kanssa) istuntoavaimen tuottamiseksi. Koska PUF-materiaali on sidottu fyysiseen laitteistoon, istuntoavaimen kloonaaminen vaatii laitteiston fyysistä kloonaamista — huomattavasti korkeampi kynnys kuin ohjelmistovariton vaarantaminen.
AES-256 tallennetulle datalle
Kvanttijälkeinen salaus suojaa siirrettävää dataa. AES-256 suojaa välittäjätallennuksessa olevaa dataa. Corvus.Quantum toteuttaa kirjekuorisalauksen välittäjän lokisegmenteille: jokainen Kafka-lokisegmentti salataan ainutlaatuisella datansalausavaimella (DEK), joka on luotu segmenttiä kohden. DEK kääritään sitten vuokraajan avainten salausavaimella (KEK) käyttäen AES-256-GCM:ää ja tallennetaan segmentin rinnalle. KEK:ä säilytetään avainten hallintapalvelimella, ei välittäjäsolmussa — uhkatekijä, joka saa fyysisen pääsyn välittäjän tallennusmediaan, saa salatut lokisegmentit ja käärityt DEK:t, mutta ei voi purkaa DEK:ejä ilman pääsyä avainten hallintapalvelimeen.
Luokitelluille tietovirtauskuormille tämä huolten erottelu vastaa suoraan CIA-kolmion vaatimuksia: Luottamuksellisuus säilytetään AES-256 DEK -salauksella levossa ja kvanttijälkeisellä salauksella siirrossa; Eheys taataan GCM-todennustaggeilla jokaisessa salatussa segmentissä, jotka havaitsevat peukaloinnin; Saatavuus ylläpidetään Kafkan replikaatiokertoimella ja välittäjän kyvyllä palvella segmentejä uudelleen replioilta, jos ensisijainen solmu epäonnistuu. Avainten hallintapalvelin on ainoa luottamuspiste, mutta ei ainoa vikapiste — se toimii replikoidussa konfiguraatiossa laitteistoturvamodeelin (HSM) tukemana.
Corvus.Quantumin integrointi puolustuksen tietovirtaputkeen: Python SDK -läpikäynti
Seuraavat vaiheet kattavat integroinnin Python SDK:n avulla. Java SDK tarjoaa identtisen API-pinnan. Vaiheet viittaavat tähän sivuun upotettuun HowTo-skeemaan.
Vaihe 1: Asenna ja määritä tunnistetiedot. SDK todentaa mTLS:llä. Zero Trust -identiteettitarjoajasi myöntää asiakasvarmenteen, joka toimii sekä TLS-tunnistetietona että valtuutusidentiteettinä. Määritä QuantumClient varmenteen polulla, avainpolulla, CA-nipulla välittäjän varmennusketjulle ja avainten hallintapalvelimen päätepisteellä. API-avaimia tai jaettuja salaisuuksia ei käytetä — varmennus on tunniste.
Vaihe 2: Rekisteröidy käytäntömoottorin kanssa. Alustuksessa SDK suorittaa käytäntömoottorin rekisteröintikutsun, joka validoi varmenteen, tarkistaa aiheen ACL:t ja palauttaa lyhytikäisen käyttötokenin. Tämä tapahtuu läpinäkyvästi asiakkaan ensimmäisellä käyttökerralla. Jos rekisteröinti epäonnistuu — virheellinen varmennus, vanhentunut ACL, käytäntömuutos — SDK nostaa AuthorizationError-virheen ennen kuin tietovirtaustoimintoja suoritetaan. Tämä varmistaa epäonnistumisen suljettu -käyttäytymisen: määrittämättömät tai väärin määritetyt asiakkaat eivät voi vahingossa suoratoistaa salaamatonta dataa.
Vaihe 3: Valitse avainjakelun profiili. Saatavilla on kolme profiilia. KD_QKD_PRIMARY käyttää QKD:tä ensimmäiseen avainvaihtoon ja palautuu ML-KEM:iin muissa kuin QKD-yhteyksissä. KD_PUF_PRIMARY käyttää PUF-laitteistoa ensisijaisena entropialähteenä ja vaatii PUF-yhteensopivan HSM:n. KD_KYBER_ONLY on vain ohjelmistopohjainen ja sopii ympäristöihin ilman QKD-infrastruktuuria. Aseta istuntoavaimen TTL ja turvallinen epäonnistumiskäyttäytyminen (FAIL_CLOSED tai CONTINUE_WITH_CACHED_KEY) yhteyskatkolle.
Vaihe 4: Tuota salattuja viestejä. Kääri vakio-Kafka-tuottaja QuantumProducer-kääreeseen. Lähetysrajapinta on identtinen vakio-Kafka-tuottajan kanssa — aihenimi, avain, arvo, otsikot. SDK salaa arvon AES-256-GCM:llä käyttäen istuntoavainta, upottaa avaintunnisteen varattuun otsikkokenttään ja toimittaa salatun hyötykuorman välittäjälle. Skeemamuutoksia ei tarvita. Pakkaus sovelletaan ennen salausta, jotta vältetään salakirjoituksen laajeneminen mitätöimästä pakkauksen hyödyt.
Vaihe 5: Kuluta ja pura salaus. Kääri vakio-Kafka-kuluttaja QuantumConsumer-kääreeseen. Kuluttaja hakee avaintunnisteen viestiotsikosta, hakee vastaavan istuntoavaimen paikallisesta avainvälimuistista (tai hakee uudelleen avainten hallintapalvelimelta, jos vanhentunut) ja purkaa hyötykuorman salauksen. Kuluttajaryhmät, siirtymien vahvistukset ja osioiden uudelleenjakautuminen toimivat identtisesti vakio-Kafkan kanssa. Sovelluksen viestienkäsittelykoodi vastaanottaa selkotekstiä — salauksen purku on läpinäkyvä.
Vaihe 6: Ota levosalaus käyttöön. Aseta at_rest_key_id asiakasmäärittelyssä aktivoidaksesi välittäjäpuolen lokisalauksen. SDK provisioi DEK/KEK-hierarkian automaattisesti. Tämä vaihe edellyttää, että välittäjäsolmuilla on Corvus.Quantum-tallennusplugin asennettuna — Kafka-tallennuskerroksen sieppari, joka käsittelee lokisegmenttien salauksen/purun ennen levyn I/O:ta.
Vaihe 7: Seuraa ja rotoi. Ota telemetrianviejä käyttöön välittääksesi käyttötapahtumat, käytäntöpäätökset ja avainten nouto-tapahtumat SIEM-järjestelmääsi. Määritä hälytykset salauksen purkuvirheille (mahdollinen avainristiriita tai uusintatoisintohyökkäys), käytäntötarkistusvirheille (mahdollinen luvaton käyttö) ja avainten noutoviiveelle, joka ylittää TTL-kynnyksen (yhteyden heikkenemisvaroitus). Aikatauluta avainten rotaatio 24 tunnin välein tai toimintavaiheen siirtymissä.
Keskeinen havainto: Yllä olevat seitsemän integrointivaihetta voidaan suorittaa yhdessä insinöörisprintissä tiimille, jolla on olemassa oleva Kafka-kokemus. SDK:n suunnittelufilosofia on API-yhteensopivuus vakio-Kafka-asiakaskirjastojen kanssa — QuantumProducer ja QuantumConsumer ovat pudotettavissa olevia korvikkeita KafkaProducer- ja KafkaConsumer-luokille. Kvanttijälkeiset ja Zero Trust -kerrokset ovat infrastruktuurin huolenaiheita, eivät sovelluksen huolenaiheita. Sovellusohjelmoijien ei tarvitse ymmärtää hilosalausta integroidakseen SDK:n — he konfiguroivat profiilin, käsittelevät AuthorizationErrorin ja kirjoittavat vakio-Kafka-koodia.
Käyttäytyminen heikentyneen verkon olosuhteissa
Puolustuksen tietovirtaus ei toimi ihanteellisissa verkko-olosuhteissa. Corvus.Quantum on suunniteltu erityisesti kiistanalaisiin ja heikentyneisiin verkkoympäristöihin — vaatimus, joka on validoitu sen operatiivisella käyttöönotolla Ukrainan taistelualueilla, joissa droonikommunikaatiot kulkevat häirityissä ja ajoittain saatavilla olevissa yhteyksissä.
Kun yhteys avainten hallintapalvelimeen katkeaa, välimuistiin tallennetut istuntoavaimet jatkavat toimintaansa TTL-arvonsa keston ajan. 30 minuutin TTL tarkoittaa 30 minuutin katkosikkunaa, jonka aikana tietovirtaputki jatkaa normaalia toimintaansa. Kun TTL vanhenee ilman uudelleenyhdistymistä, käyttäytymistä ohjaa turvallinen epäonnistumiskäytäntö: FAIL_CLOSED pysäyttää tietovirtauksen estääkseen salaamattoman palautuksen; CONTINUE_WITH_CACHED_KEY laajentaa avaimen voimassaoloa käyttäen PUF:sta johdettua materiaalia (saatavilla PUF-yhteensopivalla laitteistolla) offline-avainten johtamiseen, jatkaen salattua tietovirtausta ilman avainpalvelinyhteyttä. Uudelleenyhdistymisessä avainten vaihto on automaattinen — SDK havaitsee uudelleenyhdistymisen, suorittaa uuden ML-KEM-avainkapseloinnin avainpalvelimen kanssa ja jatkaa tietovirtausta uudella istuntoavaimella.
Lisätietoa ilmaraollisista ja katkaistuista käyttöönottokuvioista luokitelluille kuormille, mukaan lukien offline-avainten hallintatavat, löytyy omistetusta arkkitehtuurikäsittelystämme. Artikkeli Zero Trust sotilasverkoille käsittelee täyttä käytäntömoottori- ja pilarimuotoa syvällisesti, mukaan lukien katkaistujen verkkojen mukautukset, jotka täydentävät Corvus.Quantumin turvallisen epäonnistumisen suunnittelua.
Usein kysytyt kysymykset
+Mikä tekee Corvus.Quantumista kestävän kvanttitietokonehyökkäyksiä vastaan?
Corvus.Quantum käyttää hilapohjaisia salausalgoritmelja — erityisesti NTRUEncryptia ja CRYSTALS-Kyberiä — jotka ovat matemaattisesti immuuneja Shorin algoritmille. Shorin algoritmi on se kvanttilaskenta-algoritmi, joka kykenee murtamaan RSA- ja elliptisen käyrän salauksen. Hilaongelmilla (lyhin vektori -ongelma, virheellä oppiminen) ei ole tunnettua kvanttinopeutusta, joten salaus on turvallinen sekä klassisia että kvanttivastustajia vastaan. NIST standardoi CRYSTALS-Kyberin ML-KEM-nimellä vuonna 2024, mikä tarjoaa lisäkerroksen standardienmukaisuuteen.
+Kuinka Zero Trust on vuorovaikutuksessa Corvus.Quantumin kvanttijälkeisen salauskerroksen kanssa?
Zero Trust hallinnoi identiteettiä ja pääsynhallintaa — se vastaa kysymykseen siitä, kenellä on lupa tuottaa tai kuluttaa tiettyä Kafka-aihetta. Kvanttijälkeinen salaus hallinnoi luottamuksellisuutta — se varmistaa, että siepattua salakirjoitusta ei voida purkaa edes tulevaisuuden kvanttivastustajan toimesta. Nämä kaksi kerrosta täydentävät toisiaan: Zero Trust estää luvattomia solmuja liittymästä tietovirtauksen topologiaan, kun taas kvanttijälkeinen salaus suojaa siirrettävää dataa kerää-nyt-pura-myöhemmin -hyökkäyksiltä riippumatta siitä, onko vastustaja siepannut TLS-istunnon.
+Mitä tapahtuu Corvus.Quantum-virroille, kun yhteys avainpalvelimeen katkeaa?
Corvus.Quantum on suunniteltu heikentyneen verkon ympäristöihin. Alusta tallentaa istuntoavaimet paikallisesti määritettävissä olevalla elinaika-arvolla (TTL). Yhteyskatkon aikana lennossa olevat viestit jatkavat salausta ja purkua välimuistiin tallennettujen avainten avulla, kunnes TTL vanhenee. Kun TTL vanhenee ilman uudelleenyhdistymistä, alusta joko siirtyy ennalta varattuja hätäavaimia käyttämään (fyysisen kloonaamattoman funktion laitteistolla varustetuille alustoille) tai siirtyy määritettävissä olevaan turvaepäonnistumistilaan. Avainten vaihto tapahtuu automaattisesti uudelleenyhdistymisen yhteydessä.
+Voiko Corvus.Quantum toimia paikallisesti ilman pilvipalveluriippuvuuksia?
Kyllä. Corvus.Quantum ottaa Apache Kafkan käyttöön paikallisesti ilman pakollista pilvikomponenttia. Avainten hallintapalvelin, käytäntömoottori ja kaikki tietovirtavälittäjät voivat toimia kokonaan ilmarakoverkossa. Azure Event Hubs on tuettu vaihtoehtoisena välittäjänä organisaatioille, jotka haluavat hallinnoidun pilvipohjan, mutta se ei ole pakollinen. Python- ja Java-SDK:t abstrahoivat välittäjävalinnan, joten asiakaskoodi on identtinen molemmissa käyttöönottomalleissa.
+Kuinka kaksoisavainjakelu toimii — mitä ovat fyysisesti kloonaamattomat avaimet?
Corvus.Quantum käyttää kahta toisiaan täydentävää avainjakelumekhanismia. Kvanttinen avainjakelu (QKD) käyttää kvanttisia optisia kanavia (tyypillisesti kuitua) symmetristen avainten vaihtamiseen informaatioteorian mukaisella turvallisuudella — mikä tahansa sieppausyritys häiritsee fyysisesti kvanttitilaa ja on havaittavissa. Fyysisen kloonaamattoman funktion (PUF) avaimet johtavat salausmateriaalin piilaitteen valmistusvaihteluista tuottaen sormenjäljen, jota ei voida kloonata tai purkaa. Kunkin istunnon osalta molemmat mekanismit osallistuvat istuntoavaimen johtamiseen, joten yhden kanavan vaarantaminen ei vaaranna istuntoavainta.