HU231270B1 - Adatkezelő eljárás és regisztrációs eljárás anonim adatmegosztó rendszerhez, valamint adatkezelő és azt tartalmazó anonim adatmegosztó rendszer - Google Patents

Adatkezelő eljárás és regisztrációs eljárás anonim adatmegosztó rendszerhez, valamint adatkezelő és azt tartalmazó anonim adatmegosztó rendszer Download PDF

Info

Publication number
HU231270B1
HU231270B1 HU1600099A HUP1600099A HU231270B1 HU 231270 B1 HU231270 B1 HU 231270B1 HU 1600099 A HU1600099 A HU 1600099A HU P1600099 A HUP1600099 A HU P1600099A HU 231270 B1 HU231270 B1 HU 231270B1
Authority
HU
Hungary
Prior art keywords
data
identifier
data source
entity
key
Prior art date
Application number
HU1600099A
Other languages
English (en)
Inventor
Ferenc Vágujhelyi
Magyar Gábor dr.
Original Assignee
Xtendr Zrt.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Xtendr Zrt. filed Critical Xtendr Zrt.
Priority to HU1600099A priority Critical patent/HU231270B1/hu
Priority to PCT/HU2017/000012 priority patent/WO2017141065A1/en
Priority to US16/306,709 priority patent/US11263344B2/en
Publication of HUP1600099A2 publication Critical patent/HUP1600099A2/hu
Publication of HU231270B1 publication Critical patent/HU231270B1/hu

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G06F21/6254—Protecting personal data, e.g. for financial or medical purposes by anonymising data, e.g. decorrelating personal data from the owner's identification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G06F21/6263—Protecting personal data, e.g. for financial or medical purposes during internet communication, e.g. revealing personal data from cookies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6272—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database by registering files or documents with a third party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms

Description

9635R
Adatkezelő eljárás és regisztrációs eljárás anonim adatmegosztó rendszerhez, valamint adatkezelő és azt tartalmazó anonim adatmegosztó rendszer
A találmány adatkezelő eljárás és regisztrációs eljárás anonim adatmegosztó informatikai rendszerhez, valamint adatkezelő és azt tartalmazó anonim adatmegosztó rendszer. A találmány lehetővé teszi anonim adatforrások egymástól védett adatainak kölcsönös elemzését az adatentitások egyetemes egyediségének megőrzésével
Számos,, az anonimitást védő adatgyűjtő és elemző módszert használnak napjainkban. Ezek alapvetően két csoportra oszthatók. Az elsőben az anonimitást csak az adatbázishoz hozzáférő ügyfélkörrel szemben őrzik meg. Az adatok összegyűjtéséért, feldolgozásáért, tárolásáért és a lekérdezések kiszolgálásáért (továbbiakban központi adatkezelő funkciókért) felelős technikai szereplő vagy szereplők előtt nem anonimek az adatokban reprezentált entitások. A másodikban az adatforrások nem rendelnek egyedi azonosítót az entitásokhoz, ezért azok azonosítása összes tulajdonságuk egyediségének felismerésére épül. Ha ezek a tulajdonságok pontosan elkülönítik az entitásokat, akkor könnyű felismerni őket, ha nem, sok esetben egyetlen anonim entitáshoz lesznek rendelve a különböző entitásokat leiró adatok. Ilyenkor hibás lesz az entitások kapcsolatából konstruált hálózat. Mivel az adatbázisba való adatfelvételkor az azonos entitáshoz tartozó adatokat a lekérdezések sikeres kiszolgálása érdekében logikailag ősszekapcsoltan kell tárolni, ezért a jelenleg használt módszerek esetén elvi akadálya van annak, hogy a központi adatkezelő funkciókat ellátó szereplőt vagy szereplőket korlátozzuk az entitások felismerésében. Ez a hiányosság azért nem jelentős akadálya ma az ilyen célú adatgyűjtésnek és adatszolgáltatásnak, mert az elemzési célú adatgyűjtő rendszerekkel szemben támasztott igényeket e korlátok figyelembe vételével fogalmazzák meg, így lemondva a kiaknázható előnyök egy részéről.
~2
A különböző adatforrások védett adatainak közös adatbázisba töltésére tehát több eljárás és rendszer ismert. Az entitások anonim azonosítóhoz rendelését ezekben központi adatkezelő feladatokat ellátó szolgáltató végzi. Az ismert eljárások és rendszerek első csoportja szerint az entitásokat olyan új azonosítóval látják el, melyből önmagában, további információ nélkül a reprezentált entitás (például természetes vagy jogi személy, dolog, objektum, bizonylat stb.) nem felismerhető. Igyekeznek továbbá a kapcsolat bijaktív tulajdonságát (azaz kölcsönösen egyértelmű megfeleltethetőségét) biztosítani, egy adott univerzális azonosító (az entitás olyan azonosítója, mellyel arra a különböző adatforrások hivatkoznak:, mint pl. társadalombiztosítási szám, cégjegyzékszám, helyrajzi szám, bizonylatszám stb.) és az új azonosító között. Az ilyen rendszerben tárolt entitás így egy külső szereplő számára anonimmé válik.
Az anonimitásnak az attribútumok együttesének egyediségére épülő feltöréséi általában a k-anonímitás (Latanya Sweeney 2002, http://dataprivacylab.org/dataprivacy/projects/kanonymity/kanonymity.pdf) módszerével kerülik el. Ezen eljárások közős hiányosságé, hogy ahhoz, hogy valaki eldöntse, hogy egy adott entitásnak van-e már anonim azonosítója az adattárban, szükséges az univerzális azonosítók és az új azonosítók közti reláció (kapcsolati tábla) ismerete. Az ismert rendszerekben nem volt követelmény, hogy a bijektív (azaz kölcsönösen egyértelmű) leképezést az anonim adatok irányából a nyílt adat irányába csak az eredeti adatforrás tudja végrehajtani. így van egy, az adatforrásoktól különböző szereplő a folyamatban, aki nem csak megismeri az entitást, de a reláció ismeretében bármikor dé-anonlmizálni tudja az összes adatot. Ilyen szereplő kiválasztásában, az általában egymás versenytársaként működő adatforrások - az adatok esetleges anonimitás feltöréséből származó jelentős érdeksérelemtől való félelmükben — jellemzően nem tudnak megállapodni.
Ismert módszerek második csoportja szerint az adatforrások csak az entitás attribútumait küldik el az adattár adatkezelőjének. Ö azután ezeket entitás leírónak tekintve — valamilyen hasonlóságot mérő eljárást alkalmazva — a korábban tárolt adatok közül, ugyanolyan vagy hasonló attribútumokkal rendelkező korábban generált entitást rendel hozzá, vagy ilyen hiányában új
-3entításként veszi fel Az elegendően hasonló entitásokat közös, az anonimitást védő azonosítóhoz rendeli. A módszer hiányossága, hogy csak akkor működik kellő megbízhatósággal ha az egyedi azonosításhoz elegendő mennyiségű attribútum kerül az adattárba. E nélkül az egyediség megállapításához szükséges attribútum összehasonlításokat nem lehetséges végrehajtani, azaz különböző entitásokhoz tartozó adatok fognak hibásan egy entitáshoz kapcsolódni: az anonim és a nyílt adat közti leképezés már nem feltétlenül bqektiv. Ha azonban egy, az entitásra különösen jellemző adat érkezik az adattárba, melyből az univerzális azonosító megállapítható, akkor az adattárhoz hozzáférők az entitás összes ott tárolt, információját hozzá tudják kapcsolni, feltörve annak anonimitását A módszer működéséhez szükséges mennyiségű attribútumra tehát az anonimitás feltörésére irányuló támadást is fel lehet építeni. Ez az adatbázis tehát éppen akkor elemezhető jól ha könnyen feltörhető. Az ilyen adatgyűjtésen alapuló együttműködés tervezésekor a biztonságot preferáló résztvevők elemzésre kevéssé használható adatbázist hoznak létre, míg a hatékony elemzési tehetőségeket preferálók az anonimitás megőrzését veszélyeztetik.
A jelenleg alkalmazott ismert módszerek tehát egyrészt arra épülnek, hogy az adatgyűjtést végző szereplőben meg kell bízni, mivel ö ismén az entitások egyedi azonosítóit. Az anonimitáshoz fűződő súlyos érdek esetén ez elfogadhatatlan. Másik megoldásként egyedi azonosításra alkalmas adatokat nem gyűjtenek, de statisztikai módszerekkel az adatgyűjtő igyekszik felismerni az egyenként azonosításra nem alkalmas leíró adatokból azokat, melyek valószínűleg ugyanazt az entitást igák le. Ekkor a begyűjtött adatok csak statisztikai értelemben elemezhetőek, az egyes anonim entitásokra és azok kapcsolatára vonatkozó elemzés biztonsággal nem végezhető.. Például konkrét kivételek keresése helyett inkább a kivételek statisztikus gyakorisága vizsgálható.
Napjainkban anonim elemzésre tipikusan cégek vagy állami hatóságok kínálnak fel adatokat. Cégek esetén leginkább a sok ügyfeles lakossági szolgáltatók a jellemzőek. Például több online videó kölcsönző anonimízáit adatbázisa nélkülözhetetlen fonása lehet egy szociológiai kutatásnak. A video kölcsönzők
- 4 természetesen felelnek azért, hogy ügyfeleikről, illetve a hozzájuk tartozó fogyasztási szokásokról ne kerüljön nyilvánosságra adat. Az ügyféllista egymás előtti titkossága saját gazdasági érdekük, ügyfeleik preferenciáinak védelmére pedig a személyes adatok védelméről szóló jogszabályok kötelezik őket. Ha tehát egy tudományos kutatás a filmkölcsönzési szokásokat akarja társadalmi méretekben elemezni, akkor az adatforrásnak tekintett, kölcsönzőktől olyan adatokat kellene bekérnie, melyeket egymás előtt is titkolnak. A kutatónak persze nem kell tudnia, hogy személy szerint ki milyen filmet kölcsönöz, hanem elegendő, ha a földrajzi és szociológiai környezet, a nem. az életkor, az iskolai végzettség, a családi állapot, jövedelmi helyzet kerül a kölcsönzött alkotáshoz hozzárendelésre. Ha az adatkör nem túl széles, és az egyes jellemzők felbontása nem túl nagy (pl. születési dátum helyett elég az, hogy 40-45 év közötti), akkor az ügyfél nem azonosítható, és az elemzési cél Is megvalósulhat.
Vannak olyan esetek, amikor az elemzett adathalmazban reprezentált entitások (pl. cégek, személyek, járművek, ingatlanok, bizonylatok stb.) közötti kapcsolatokból épített hálózatok topológiáját keli elemezni. Jó példa erre a hálózatos csalások felderítése. Ilyenkor nem lehet statisztikai alapon létrehozni az entitások anonim azonosítóit, hanem jól definiált bíjektív kapcsolatra van szükség az entitások univerzálisan ismert és az adatbázisban használt anonim azonosítói között. Az adatforrások ilyenkor tipikusan kiválasztanak egy olyan, a központi adatkezelésért felelős szolgáltatót, aki ismeri az entitások nyílt azonosítóit, és generálja az anonim azonosítókat. Ebben az esetben a központi adatkezelő funkciókat ellátó szervezetben meg kell bízniuk az adatforrásoknak, hiszen ö bármikor fel tudja törni az anonimitást, mivel a leképezést maga hozta létre. A technika jelenlegi állása olyan esetekben nem nyújt megoldást, amikor nincs olyan központi adatkezelő, akiben az adatforrások valamennyien megbíznának, ugyanakkor rendkívül erős érdekük fűződik az adatbázisaikban reprezentált hálózatok egyesített elemzéséhez.
A technika állása szerint olyan eljárások és rendszerek is ismertek, amelyekben több adatforrásból származó adatot aggregálnak oly módon, hogy az adatforrások anonimitását fenntartják. Az US 2005/0165623 A1 dokumentumban ismertetett rendszer azonos titkosító kulcsot alkalmaz minden egyes adatforrásra az adatforrás azonosítójának titkosítására, amelynek révén az egyes paciensekre vonatkozó egészségügyi információk anonim módon gyűjthetők és vizsgálhatók. Az US 2006/0085454 A1 dokumentumban is ehhez, hasonló rendszert, ismertetnek, amelyben megjelenik a megbízható harmadik fél is, amely az. adatkonverziókat, összerendezéseket védett módon kezeli. A GB 2469673A dokumentumban több adatforrás azonos kulccsal titkosított azonosítókat továbbít egy központi, kombinált adatbázisba. A DE 10 2010 037 326 A1 dokumentum Is anonim módon történő aggregációt lehetővé tevő adat-rendszert ismertet. A WO 2014/082648 A1 dokumentumban is olyan megoldást ismertetnek, amelyben anonímizált módon aggregálnak, továbbítanak adatot. Ezen dokumentumok egyikében sem ismertetnek olyan rendszert, amely biztosítaná a jelen találmány későbbiekben deklarált célkitűzéseit és a - rendszerből megismert adatok esetén — a minden résztvevő számára fennálló anonimitást.
A találmány célja olyan megoldás létrehozása, amely a lehető legnagyobb mértékben kiküszöböli az eddig ismert módszerek hátrányait. A találmány célja különösen olyan megoldás létrehozása, melynek alkalmazása esetén a leíró adatok (attribútumok) mindig olyan rejtjelezett azonosítóhoz kötődnek, mely bijeklív kapcsolatban van az eredeti azonosítóval. így az anonimitás védelme és az elemezhetőség egyszerre biztosított.
A találmány a következő alapfelállás területén ad megoldást az anonimitásra. Adott számos adatgazda, akiknek saját adatbázisuk van. Az adatbázisokban tárolt adatok például entitások közötti kapcsolatokat és e kapcsolatok jellemzőit (attribútumait) reprezentálják, melyekről tegyük fel, hogy mások elöl védendő, bizalmas információt tartalmaznak. Ilyenek például a gazdasági kapcsolatokat reprezentáló bizonylatok (számlák, szállítólevelek, pénzfogalmi adatok). Az entitások közötti relációkból hálózat építhető. A hálózat lehető legteljesebb felépítéséhez egyesíteni kell az adatbázisokban tárolt adatokat. Az így létrehozott hálózaton végzett elemzésekhez az adatgazdáknak érdeke fűződik, de az adatok mások számára felismerhető formában való megosztását el kell kerülniük. Sok olyan feladat van, ahol a keresett információt az entitások közötti kapcsolat hálózati jellemzőinek elemzésével lehet megtalálni. A csalásfelderítés eszköztára egyre inkább egy azonosított entitás köré épülő hálózat topológiájának megismerésére épül. A csalási kockázat felismeréséhez a hálózat csúcsait alkotó entitások lehetnek anonimek, de a hálózat helyes (izomert) felépítéséhez az anonim címke és az entitás közötti kapcsolatnak bijektívnek kell maradnia. A találmány olyan megoldást nyújt a problémára, melyben a mástól származó adatok anonimitása mind az elemzők, mind a központi adatkezelő (továbbiakban: adatkezelő) funkciókat ellátó személy vagy szervezet számára megmarad, azaz a résztvevőknek' nem kelt megbízniuk egymásban.
A találmánnyal megoldani kívánt probléma tehát különösen az, hogy úgy gyújtsunk adatokat több adattárból (más szóval adatbázisból) egy közös adattárba (adatbázisba), például azonosítható entitások közötti kapcsolatok sokaságáról, hogy azok senki számára ne legyenek azonosíthatóak az adattárhoz történő illetéktelen hozzáférés vagy több résztvevő rossz szándékú együttműködése esetén sem, ugyanakkor a kapcsolatokból alkotott hálózat topológiája ne változzon .
Adott tehát jelentős számú adatforrás, melyek mindegyikének van saját adatbázisa. Az adatbázisokban ugyanazzal az adattal (pl. EU adószám) azonosítható entitások közötti kapcsolatok (pl. számlák) kerültek tárolásra. A feladat a helyi adatbázisokban tárolt összes kapcsolati adatból, egy adatkezelő közreműködésével egy közös adattár létrehozása úgy, hogy a) az adatforrások az entitás-azonosítókat rejtjelezve továbbítsák, b) az entitások és az adatforrások tegyenek anonimek a folyamatban résztvevő adatkezelő számára, c) az adatforrás előnyösen kapjon visszaigazolást az általa szolgáltatott adatról, melynek hitelességét az adatkezelő ellenőrizni tudja, d) a közös adattárban tárolt adatokból, adott entitás-azonosítóhoz hálózatosán kapcsolódó adatokra lehessen lekérdezést végrehajtani úgy, hogy a lekérdezésben továbbított paraméterekre a b) feltétel teljesüljön,
.. 7 -
e) a d) feltétel szerinti eredményben szereplő anonim entitás-azonosító legyen különböző minden lekérdezőre, de egy adott lekérdezés eredményében egyetlen értékként szerepeljen,
f) az adattárban az entitások azonosítóit úgy kell tárolni, hogy akár azok illetéktelenhez kerülése és/vagy a folyamatban szereplők ellenséges szándékú együttműködése esetén se legyen képes senki a nyílt entitás-azonosítókat visszafejteni.
A fenti feladat megoldását, illetve a kitűzött célt az 1. igénypont szerint adatkezelő eljárással, a 9. igénypont szerinti regisztrációs eljárással, a 11. igénypont szerinti adatkezelővel és a 15. igénypont szerinti anonim adatmegosztó rendszerrel értük el. A találmány előnyős kiviteli alakjai az aligénypontokban vannak meghatározva.
A találmány szerinti feladat megoldásához az a)-f) feltételeket teljesítő alábbi következtetések vezettek, amelyek részben a föigénypontokban definiált találmányok, részben pedig az aligénypontokban definiált előnyös kiviteli alakok jellemzőit határozzák meg.
Első következtetés (az entitás-azonosítót reprezentáló titkosított adatok közös azonosítójó osztályhoz rendelése, az osztályozó kulcs szükségessége):
Az a) feltétel az entitások anonimitását biztosítja. Egy entitás minden adatforrás számára ugyanazon értékkel azonosított (pl. társadalombiztosítási szám). Ezt az értéket a) szerint, saját egyedi rejtjelező leképezésüket használva az adatforrások annyi értékre képezhetik, ahányan vannak. Ha egy d) feltétel szerinti lekérdezés során a keresett entitás különböző adatforrásokból származó adatait meg akarjuk találni, akkor a számos adatforrás titkosítása során különböző értékekre képezett azonosítóját egyetlen, az anonimitást védő értékre keli leképezni (osztályozás) és az adattárban tárolni. A leképezést végrehajtó függvényt hívjuk osztályozó függvénynek.
Második következtetés (az osztályozó leképezéseket csak az adatkezelő ismerheti):
Az entitásoknak és az adatforrásoknak anonimeknek kell maradniuk az adatkezelő előtt. Az a) feltétel biztosítja az entitás anonimitását. Az adatot fogadónak úgy kell, a b) feltételnek megfelelően, az adatforrás anonimitását biztosítani, hogy ugyanakkor fel kell ismernie: a titkosított adatot melyik függvény használatával kell a közös anonim értékre leképeznie (osztályoznia). Ezt a leképezést viszont az adatforrás az f) feltétel miatt nem ismerheti, azaz ö nem adhatja oda. Ha ugyanis ismerné, akkor az -entitás-azonosítókat maga is közvetlenül le tudná képezni az adattárban tárolt értékekre. Ha pedig az adattárhoz hozzáférne, akkor próbálgatással· entitás-azonosítóról - entitásazonosítóra egyenként képesek tennének feltörni az adattári titkosítást, melyet az f) feltétel tilt. Ezért, az adatforrásnak egy olyan anonim azonosítót kell a beküldött titkosított adathoz mellékelnie, mely alapján az adatkezelő ki tudja választani az osztályozáshoz szükséges leképezést.
Harmadik következtetés (regisztráció és a független regisztrátor szükségessége):
Az adatforrásnak tehát előbb regisztrálnia kell egy független szolgáltatónál· aki anonim azonosítóját neki és az adatkezelőnek, saját titkosító függvényét csak neki, az ehhez tartozó osztályozó függvényt pedig csak az adatkezelőnek átadja. A szolgáltató az általa előállított függvényeket ezt követően nem tárolja. A módszer használhatóságát nem befolyásolja hátrányosan, ha egy adatforrás többször regisztrál, és teljesen rendszertelenül küld vagy kérdez le adatokat különböző azonosítói és a. hozzájuk tartozó titkosító kulcsok segítségével.
Negyedik következtetés (az adattár osztályozott adataiból készített jelentéseket adatkezelő a lekérdezőhöz tartozó egyedi jelentő függvénnyel leképezve adja át): A lekérdezés eredményét az e) feltétel miatt nem szabad az adattárban tárolt formában átadni, mert így a lekérdezők nem különböző anonim entitásazonosítóval reprezentálva kapnának adatot. A feltétel azért fontos, hogy az anonimitás feltörésének céljából ne tudjanak összehangoltan lekérdezni és annak eredményét egyesítve nagyobb adatkört közösen elemezni. Ezért az adatkezelő entitás-azonosítót csak a jelentő függvénnyel leképezve ad át a lekérdezőknek. Ezek a függvények más-más leképezést valósítanak meg, de adott lekérdezés eredményében, mindig ugyanazt. A d) feltételben a lekérdezések paramétereire vonatkozó b) feltétel miatt már az entitás-azonosító paraméterek osztályozásához is szükség van a lekérdező anonim azonosítójára. Ugyanezen azonosító segít a jelentőkulcs kiválasztásában. A fentiekből következik, hogy a lekérdezőnek regisztrált adatforrásnak is kell lennie. A jelentő kulcsot a harmadik következtetésben leírt; regisztrációt végző független szolgáltató generálja és adja át az adatforrás anonim azonosítójához kapcsoltan az adatkezelőnek.
Ötödik következtetés (tranzakció azonosító használatának szükségessége):
Ha minden lekérdező a teljes adattárról korlátlanul kérhet jelentést, azaz az adattárat a jeientőfüggvénnyel leképezve teljes egészében letöltheti, akkor a hálózat topológiai jellemzőire támaszkodó anonimitás feltörés kockázata megnő, A lekérdezésekre hozható olyan szabály, hogy a hálózatos kapcsolatok felépítése csak olyan adatszolgáltatásban szereplő adatelemből indulhat, melynek a lekérdező az adatforrása. Ha az adatkezelő a c) feltételnek megfelelően, egy egyéb információt nem hordozó tranzakció azonosítót generál, melyet az adattárban a rögzített adathoz kapcsol és az adatforrásnak hitelesítve is átad, úgy az adatkezelő meg tud győződni róla, hogy adott adatelem a lekérdezőtől származik. Ehhez előnyösen az szükséges, hogy a lekérdezést indító adatforrás mutassa be a paraméterként átadott tranzakció azonosítókhoz tartozó c) feltételnek megfelelő hiteles visszaigazolásokat.
A továbbiakban a találmány példaképpen! előnyös kiviteli alakjait rajzokkal ismertetjük, ahol az
1. ábra a titkosított entitás-azonosítók közös titkosított értékre történő példaképpen! leképezésének (osztályozás) vázlata, a
2. ábra egy példaképpen! regisztráció folyamatának vázlata, a
3. ábra egy példaképpen! adatszolgáltatás folyamatának vázlata, a
4, ábra egy példaképpen! lekérdezés folyamatának vázlata, és az
5. ábra egy példaképpen! adatfolyam vázlata.
- 10Az 1. ábrán látható vázlat szerint az azonosíthatóság megakadályozása céljából 10 adatforrásoknak felismerhetetlenné kell tenniük (azaz rejtjelezniük kell) a tárolt entitások egyedi azonosítóit. Ehhez minden 10 adatforrásnak saját, egyedi rejtjelező kulcsot kell használnia. így egy konkrét entitás azonosítója (pl. egy szám) rejtjelezve annyi különböző értékként kerül átadásra az adatszolgáltatásban, ahány 10 adatforrás adatot küld róla. A későbbi elemezhetöség érdekében az adatgyűjtőnek, azaz 11 adatkezelőnek fel keli ismernie, hogy a különböző forrásokból, különböző kulcsokkal titkosítva érkező, ezért különböző azonosítók közül, melyek hivatkozzák ugyanazt az entitást anélkül, hogy közben az eredeti azonosítót megismerné.
A 11 adatkezelőnek tehát minden egyes 10 adatforráshoz rendelkeznie kell egy olyan függvényt megvalósító kulccsal, mély a 10 adatforrásonként más-más kulccsal rejtjelezett adatot ugyanabba, az eredetitől különböző értékbe képezi.
Az 1, ábrán ex és es tetszőleges A és B entitások entitás-azonosítóit jelölik, ti az i-edik 10 adatforrás saját titkosító kulcsa, o a t<-hez tartozó osztályozó kulcs, mely a közös értékre (pl. οα) képezi az entitás-azonosítót. A közös érték a közös anonim entitás-azonosító, amely a közös 12 adatbázisban eltárolt adatok átfogó rendszerezését, lekérdezését, teszi lehetővé. Az ábra az entitás-azonosítók és a közös anonim entitás-azonosítók közötti vonalakkal jelzi, hogy a leképezés után is megmaradnak, azaz lekérdezhetőek az entitások közötti kapcsolatok.
Egy entitáshoz például egy arra jellemző részháiózatí struktúra tartozhat (pl egyetlen csomópont extrém sok kapcsolattal). Amennyiben az entitások közötti kapcsolatok tulajdonságainak tárolására is szükség van a. közös adatbázisban, úgy azt az adatkört úgy kell meghatározni, hogy az anonimitás feltörésére ne legyen alkalmas (pl. a postai cím egyértelműen azonosít egy céget, ha azt kizárólagosan használja). Ha az elemzési célok eléréséhez, mégis ilyen adatokra van szükség, úgy célszerűen.......a későbbiekben részletesen bemutatásra kerülő — privát kommunikációs csatornát kell az eredeti 10 adatforrás és a lekérdező között létrehozni, az anonimitás egyidejű fenntartása mellett. Ekkor a lekérdezőnek lehetősége nyílik az adatigénylés bizalmas indoklására, a 10 adatforrásnak a nyílt adatai átadására, vagy anonimitása önkéntes feladására, így a rendszeren kívüli közvetlen együttműködésre.
Az 1. ábrán vázlatosan bemutatott adatkezelő eljárás tehát anonim adatmegosztó rendszerhez alkalmazható. Az eljárás során 10 adatforrástól adatszolgáltatást veszünk, amely adatszolgáltatás tartalmaz
- anonim adatforrás azonosítót,
- a 10 adatforrás saját titkosító kulcsával titkosított entitás-azonosítót és - az entitáshoz tartozó adatot, amely adat tipikusan nyílt, azaz kódolatlan adat, mely a lekérdezésekben kódolatlanul ismerhető meg.
Az eljárás során továbbá egy az adatforrás azonosítóhoz tartozó osztályozó kulccsal a titkosított entitás-azonosítót közős anonim entitás-azonosítóra leképezzük oly módon, hogy minden entitás-azonosítóra teljesül· hogy azt bármely 10 adatforrás saját titkosító kulcsával titkosítva és az adatforrás azonosítójához tartozó osztályozó kulccsal leképezve ugyanazon közös anonim entitás-azonosítót kapjuk. A leképezést követően az entitáshoz tartozó adatot a közös anonim entitás-azonosítóhoz rendelten a 12 adatbázisban eltároljuk.
A 2. ábrán látható regisztrációs folyamat során, ha egy új 10 adatforrás csatlakozni kíván a rendszerhez beadja igényét annak a szolgáltatónak, azaz 13 regisztrátornak, aki a kérelem alapján kővetkező adatokat generálja:
~ a 10 adatforrás azonosítóját (af.i.íd), melyet a 10 adatforrásnak átad,
- a 10 adatforrás titkosító függvényét vagy kulcsát (af.i eno), melyet a 10 adatforrásnak átad,
- a 10 adatforráshoz vagy adatforrás azonosítójához (af.i.íd) tartozó osztályozó függvényt vagy kulcsot (ak.osztJ.enc), melyet a 11 adatkezelőnek átad, és
- a 10 adatforráshoz vagy adatforrás azonosítójához (af. i id) tartozó jelentő függvényt vagy kulcsot (ak.rep.i.enc), melyet, a 11 adatkezelőnek átad.
A kulcsok által reprezentált kriptográfiai leképezések diszkrét értékek közötti függvénykapcsolatot valósítanak meg, ezért tekinthetőek hozzárendelési táblázatnak vagy kriptográfiai módszernek. A jelen találmány szerint kulcson az általa megvalósított leképezést (függvényt) is értjük, és e kifejezéseket egymással egyenértékű módon használjuk.
A fenti titkosító függvények vagy kulcsok konstruálásához az egyik lehetséges kriptográfiai módszer az RSA szabvány (Id. pl. US 4,405,829) lehet. Ennek során előnyösen
- az RSA szerinti inverz kulcsok, a 10 adatforrás titkosító kulcsa inverzének (af.i.dec) kivételével nem kerülnek legenerálásra,
- a kulcsok generálásáért felelős 13 regisztrátor rendelkezik egy saját kriptográfia kulccsal (reg.enc),
- a 13 regisztrátor megképzi a kérelmező 10 adatforrás saját titkosító (af.i.enc) kulcsát és annak inverzét (af.i.dec), és a jelentő kulcsot (ak.rep.i.enc),
- az osztályozó kulcs (ak.osztJ.enc) a 10 adatforrás titkosító kulcsának inverzével (af.i.dec), majd a 13 regisztrátor saját kulcsával (reg.enc) ebben a sorrendben végrehajtott leképezés (ak,oszij.enc(c)”reg.enc(afJ.dec(c))); ezzel biztosíthatjuk példaképpen, hogy minden entitás-azonosítóra teljesüljön, hogy azt bármely 10 adatforrás saját titkosító kulcsával titkosítva és az adatforrás azonosítójához tartozó osztályozó kulccsal leképezve ugyanazon közös anonim entitás-azonosítói kapjuk,
- az osztályozó kulcs (ak.oszt.i.enc), biztonságos kriptoprocesszorba írva kerül a 11 adatkezelőnek átadásra mely kizárja, hogy a 10 adatforrás titkosító kulcsának inverzével végzett művelet eredményét bárki megismerhesse.
A fentiek szerinti és a továbbiakban alkalmazott jelölések a következők: afj.íd: i-edik adatforrás anonim (kulcs)azonosítója, af J enő: i-edik. adatforrás titkosító kulcsa, af.i.dec: í-edik adatforrás titkosító kulcsának inverze, ak.oszt.í.enc: adatkezelő i-edik adatforráshoz tartozó osztályozó kulcsa, ak.repd.enc: adatkezelő i-edik adatforráshoz tartozó jelentő kulcsa, reg.enc: regisztrátor titkosító kulcsa, id: a titkosítandó entitás-azonosító, c ~ af.i.enc(id): az adatforrás által az adatkezelőnek beküldött adat, o ak.osztí.enc(c) ~ reg.enc(af.i.dec(c)): osztályozó leképezés, biztonságos kriptoprocesszorral végrehajtva, r2 ~ ak.rep.i.enc(o): a lekérdező által nyílt adattá nem dekódolható entitásazonosító.
Opcionálisan a jelentő kulcsokat a 13 regisztrálót helyett all adatkezelő is képezheti. Az adott 10 adatforráshoz tartozó jelentő kulcsot tetszőleges számú jelentést követően újra cserélheti a 11 adatkezelő, de adott jelentésen belül egyetlen kulcsot kell használni. Az opció következetes használatával a jelentésekből történő készletező .adatgyűjtés közvetlenül nem alkalmas a nem saját forrású adatok anonimitásának feltörésére.
A 3. ábrán látható adatszolgáltatás előnyösen úgy történik, hogy a 10 adatforrás saját titkosító függvényével (af.i.enc) titkosítja az entitás-azonosítókat és az azokhoz tartozó nyílt adatokat így küldi el a 11 adatkezelőnek saját azonosítójával (afJ.id) együtt A 11 adatkezelő az azonosítóhoz (af.iJd) tartozó osztályozó függvénnyel (ak.oszti.enc) az osztályazonosítóra, azaz a közös anonim entitás-azonosítóra képezi a titkos entitás-azonosítókat és az érkeztetett adatokban ezeket szerepeltetve adatelemenként, (rekordonként) úgy tárolja a 12 adatbázisban, hogy előnyösen egyedi tranzakció azonosítókat rendel hozzájuk. Ezt az azonosítót előnyösen elküldi az adatforrásnak, a küldés célszerűen egy hitelesített dokumentumban történik. A kommunikáció előnyösen 14 anonim adatcsatornán zajlik, ami azt. jelenti, hogy a kommunikációból az abban résztvevők nem beazonosíthatók. A regisztráció kivételével előnyösen a teljes kommunikáció az anonimitást védő és titkos adatcsatornán történik. A regisztráció esete akkor kivétel, ha a találmány konkrét alkalmazásában bárki, korlátozás nélkül lehet adatforrás.
A 4. ábrán látható lekérdezési folyamat előnyösen a következő. A lekérdezés során a 11 adatkezelő kiválogatja azokat az adatelemeket a 12 adatbázisból, melyekre igaz értéket ad a lekérdezés paramétereiből összeállított logikai
- 14kifejezés. Ha a paraméterek között entitás-azonosítók vannak, ügy azokat a 10 adatforrás, az adatszolgáltatásnál leírtak szerint saját titkosító függvényével titkosítja, majd a 11 adatkezelő az osztályozó függvénnyel leképezi. így az ilyen paraméterek már a 12 adatbázisban tárolt formában állnak a lekérdezés futtatásához rendelkezésre. A lekérdező paraméterként mellékelhet a korábbi adatszolgáltatásokra kapott hitelesített visszaigazolásokat, illetve tranzakció azonosítókat. Ez lehetőséget teremt arra, hogy a lekérdezés eredményében csak olyan adatelemek szerepeljenek, melyek hálózatos kapcsolatban vannak a visszaigazolásokban hivatkozott tranzakciókkal. A 11 adatkezelő az eredményben az entitás-azonosítókat a jelentő kulccsal leképezi, majd az adatokat a lekérdező anonimitását megőrző 14 anonim adatcsatornán átadja.
A 11 adatkezelőnél tehát a lekérdezés során a 10 adatforrástól egy vagy több entitásra kiterjedő lekérdezést veszünk, amely lekérdezés tartalmaz anonim adatforrás azonosítót és a 10 adatforrás saját titkosító kulcsával titkosított entitás-azonosítókat. Az adatforrás azonosítóhoz tartozó osztályozó kulccsal a titkosított entitás-azonosítókat a közös anonim entitás-azonosítókra leképezzük,, a lekérdezés eredményét összeállítjuk, majd a lekérdezés eredményében a közös anonim entitás-azonosítókat egy az adatforrás azonosítóhoz tartozó jelentő kulccsal titkosítjuk, és a lekérdezés eredményét ezt követően továbbítjuk a lekérdező 10 adatforráshoz.
Adott esetben az adattároláshoz tranzakció azonosítót generálhatunk, amelyet a 12 adatbázisban eltárolt adatokhoz rendelten eltárolunk, és a tranzakció azonosítót a 10 adatforrásnak visszaigazolásban - előnyösen hitelesen aláírva ~ megküldjük. Ha ekkor a lekérdezés tartalmaz (hiteles) visszaigazolást vagy tranzakció azonosítót is. ügy lehetővé tesszük, hogy a lekérdezés eredményébe csak olyan adatokat foglaljunk, amelyek a tranzakció azonosítóval (előnyösen előre meghatározott, vagy annál kevesebb gráf-élszámú) kapcsolatban vannak. A lekérdezés eredményébe célszerűen a tranzakció azonosítókat is belefoglaljuk, hogy a lekérdező a saját tranzakcióit felismerhesse, és ezzel a saját adatszolgáltatásaihoz kapcsolódó entitás-azonosítókat beazonosíthassa.
- 15Ha a lekérdező az eredményt megismerve további információhoz akar jutni, úgy a felek anonimitását védő privát adatcsatornát kell a lekérdező és az adatforrás között létrehozni példaképpen az 5. ábra Kapcsolatelvétel sorában szemléltetett módon úgy, hogy
- a 11 adatkezelővel a 10 adatforrások számára elérhetővé teszünk egy adattárolásra alkalmas eszközt, előnyösen elektronikus postaládát, amely minden 10 adatforrás számára látható két tranzakció azonosítóval jelölhető meg, a megjelölést célszerűen az végzi, aki az adattárolásra alkalmas eszközben (postaládában) üzenetet helyez el,
- a rendszer használói ismernek egy szimmetrikus rejtjelező algoritmust (f),
- a lekérdező a lekérdezés eredményéből kiválasztott tranzakcióhoz szerinte tartozó entitás vagy entitások nyílt azonosítóját (edd) használva rejtjelezi a tranzakció azonosítót (c^e.id.tr.id), ahol ez első paraméter az alkalmazott kulcs), elhelyezi egy postaládában, melyre kívülről címkeként ráírja a nyilt tranzakció azonosítót és a lekérdezés nyílt azonosítóját, ~ a továbbiakban a postaládához az anonim felek a címkéhez tartozó hiteles tranzakciós és lekérdezési visszaigazolások 11 adatkezelőnek történő bemutatásával férhetnek hozzá, ~ a 11 adatkezelő közzéteszi a 10 adatforrások között az adatkérés tárgyát képező tranzakció azonosítóját azért, hogy a tranzakcióhoz tartozó 10 adatforrás lássa a tőle származó tranzakcióra vonatkozó adatkérést és így hozzájusson a postaláda tartalmához (c),
- majd a tranzakcióhoz tartozó entitás-azonosítók közül megkeresi azt, amely az f szimmetrikus rejtjelező algoritmus kulcsaként használva a tranzakció azonosítói adja vissza nyílt adatként (melyre trJd“f(eJd,o) igaz), majd
- a 10 adatforrás ugyanezt a postaládát és rejtjelkulcsot használva a postaládán látott lekérdező azonosítót elküldi a lekérdezőnek, a közös kulcsot így visszaigazolva; ez a rejtjelezési eljárás nem erős, mivel az entitás-azonosítók értékkészlete jellemzően nem éri el a kriptográfia által igényelt számosságot, igy
- a felek e kriptográfiai leképezést előnyösen csak a Drffíe-Hellman kulcscserélő algoritmushoz (Id. pl. US 4,200,770) szükséges két üzenetváltáshoz használják így megakadályozva, hogy a 11 adatkezelő kózbeékelődéses támadást hajtson végre,
- ezt az adatcsatornát használva a lekérdező és a 10 adatforrás rejtjelezett kommunikációt folytathat egymással.
Adattárolásra alkalmas eszközként elektronikus postaládán kívül természetesen bármilyen alkalmas eszközt is használhatunk; a leírás későbbi részeiben az egyszerűség kedvéért mindenhol postaládát említünk és a postaládával megvalósított kiviteli alakot részletezzük.
Az 5. ábrán látható adatfolyam az alább részletezett jelölés-magyarázatok alapján követhető végig. A jelölések igazodnak a 2. ábra kapcsán leírtakhoz. Az aláhúzott jelölések érték n-eseket (n db típus direkí szorzatának egy elemét) jelölnek. (A típusok értékkészletei legyenek az Sí, .... Sn halmazok. Képezzük ezek Descartes-szorzatát (direkí szorzatát). Az így kapott halmaz tegyen S. Ha y eleme S~nek. akkor y~t a fenti típusok érték n-esének nevezzük. Például a valós számok önmagával vett direkt szorzata a kétdimenziós valós vektortér, melynek elemeit (a vektorokat) gyakran reprezentáljuk aláhúzott kisbetűkkel. Jeten általánosításnál azaz a típus n-eseknél is megtartjuk a jelölést.)
Adatszolgáltatás, központi tárolás:
Adatforrás anonim kulcsazonosítója: af.i.íd. saját adatbázisa: DB.i, a központi adatbázis: DB.ak
A relációban résztvevő entitások univerzális azonosítói: e - (e.1 Jd,...( e.N.id]
A reláció adattárban gyűjtött attribútumai: a.pub ~ (a. 1...... a.M}
A reláció adattárban nem gyűjtött attribútumai: a.priy ~ [a.M*1, .... a.K]
A reláció összes attribútuma: a ~ ajpub konkatenálva a.priy
A reláció adatforrásnál; r ~ e konkatenálva a (a konkatenáció itt az n-es bővítését jelenti)
Adatforrás által titkosított: c ~ af.íenc(e) (n-es argumentumra elemenként végrehajtott leképezés)
Adatforrás által átadott: m ~ faflid. c, a.pub] (az n-esen belüli n-es, vagyis kétindexes objektum)
Adatforrás az adatkezelőtől kapott tranzakció azonosítót (tr.id) r-hez rendeli, saját adattárában.
Adatkezelő érkezteti m-et af.üd alapián elvégzi az osztályozást: o ~ ak.oszt.i.enc(c)
Adatkezelő által tárolt reláció: r.oszt ™ (o, a.pub, tr.ldl
Lekérdezés:.
Lekérdező anonim kulcsazonosítója; af.j.id
Lekérdező entitás paraméterei; qe - (qe.1 Jd...., qe.P.íd]
Lekérdező attribútum paraméterek: qa ~ [qa. 1,..., qa.R], ahol a paraméterek részhalmazok határait is jelölhetik (pl időintervallumok vagy földrajzi területek).
Lekérdező hálózati gyökér tranzakciói: q.tr ~ ^qtrl, .... q.tr.S] (melyek hitelesek is lehetnek, ha fontos, hogy igazolja: ö az adatforrás)
Lekérdezés paraméterei: g ~ [qe, ga, gttj
Lekérdező által titkosított paraméterek: qc - af.j.enc(ge)
Lekérdező által beküldött paraméterek: qm ~ íafj.id, gc. ga]
Lekérdező az adatkezelőtől kapott tranzakció azonosítót (q.íd) g-hoz rendeli saját adattárában, hogy tudja, mire kap majd választ
Adatkezelő érkezteti af.j.id alapján elvégzi az osztályozást: go ak.oszt.Lenc(qc)
Adatkezelő végrehajtja a lekérdezést, melynek paramétere: poszt ~ [go, qa, q,tr|
A lekérdezés eredménye: r.oszt - [o. a.pub. tr.id], ahol az eredmény sorainak tranzakciós azonosítói a tr.id n-es.
Az eredményben az entitások jelentő kulccsal leképezve: rep.e ~ (ak.repJ(r.oszt.o)]
Lekérdezés átadott eredménye: reg - kep e, a.pub. tudj
Saját tranzakciók, adattárban nem táróit nyílt entitás azonosítói tr.id-ből: a.priv
Kapcsolatfelvétel legalább egy ismert entitásé idegen tranzakció adatforrásával (f ismert privát kulcsú kriptográfiai leképezés):
- 18 Lekérdező által feltételezetten érintett entitások a tr.íd tranzakcióhoz: ce = [e.1, ..., e.Q]
Lekérdező ezeket opcionálisan mind, de közülük legalább egyet f kulcsaként használva, sorban leképezi a tranzakció azonosító titkosított értékeire: c = f(oe, tr.id)
Lekérdező cm ~ [tr.id, q.id, ej értékeket átadja az adatkezelőnek.
Adatkezelő tr.íd és qJd elmen, mely címeket az adatforrások látnak, fiókba helyezi.
A tr.íd tranzakció adatforrása jelentkezik cm-ért, bemutatva a tr.id-hez tartozó visszaigazolást
Ha a tr.id-hez tartozó relációban létezik e.id, hogy tr.id ~ f(eJd, c), akkor ezzel a kulccsal titkosítja q Jd-t, melyet a fiókban elhelyez: cq ~ f(eJd, q.id) Lekérdező, a fiókból cq-hoz hozzáférve, megvizsgálja: ha qJd ~ f(ceJ, cq), akkor ce.i a közös kulcs.
Ezt használva Diffie-Helíman kulcscserét hajtanak végre, kialakítva a további kommunikációhoz szükséges titkos kapcsolatot.
A találmányt az alábbi példával is bemutatjuk.
Egy példaképpen! környezetben a tulajdonosok biztosítják ingatlanjaikat Ehhez biztosítótársaságok szolgáltatását veszik igénybe. Egy ingatlannak több tulajdonosa is lehet. Tegyük fel, hogy mindegyikük szabadon köthet biztosítást. Tegyük fel. hogy a biztosítóknak érdeke fűződik ahhoz, hogy ne osszák meg egymással ügyfeleik és a biztosított ingatlanok adatait illetve azt, hogy ki mit biztosít. Az ügyfeleket állandó természetes azonosítóik (születéskori név, anyja születéskori neve, születés helye és időpontja, neme) összességével, cég esetén adószámmal (továbbiakban ügyfél azonosító), az ingatlant a helyrajzi számmal és szükség esetén, az ahhoz kapcsolt albetétszámmal (továbbiakban ingatlanazonosító) azonosítjuk. Feltételezzük, hogy ezek az azonosítók egyediek. A biztosítóknak közös érdeke, hogy az ügyfeleknek soha ne álljon anyagilag érdekében káresemény bekövetkezése. Tegyük fel, hogy ez úgy garantálható, ha a kifizetett kártérítési összeg soha nem haladja meg a kár összegét. A biztosítók ezért igyekeznek ezt a kockázatot a szerződés megkötése
- 19 előtt feltárni. Ehhez ismerniük keltene, hogy egy szóban forgó ingatlan (rész)tuíajdonosa(i) korábban összesen mekkora káresemény szolgáltatási díjra kötöttek bármely biztosítónál szerződést. Ehhez létre kell hozni egy olyan adatbázist, melyben logikailag az íngatlanazonosítóhoz kapcsoltan szerepelnek az ügyfél azonosítók, a fedezett kárösszeg, a kockázatviselés kezdete, és ha a jogviszony megszűnt, a vége. Az ajánlatkéréseket is érdemes feltölteni, mivel ez is fontos kockázatkezelési információ. Az azonosítókat a biztosítók viszont nem szeretnék egymás tudomására hozni, az összeget és a dátumokat viszont önmagukban nem tekintik védendő információnak.
A találmány szerinti megoldás a következő. Először regisztrálnunk kell az adatforrásokat, azaz a biztosítókat a rendszerben. Ezt úgy kell megtenni, hogy a regisztrációt végző soha ne lássa a rendszerben gyűjtött adatokat, tehát erre a célra egy független szolgáltatót kell kijelölni, aki nem tárol semmilyen adatot. A biztosító meghatalmazottja kezdeményezi a független szolgáltatónál a regisztrációt . Az egyszerűség kedvéért ez történhet például személyesen. Miután a szolgáltató azonosította a kérelmezőt és megállapította, hogy jogosult a rendszerben részt venni, a fentieknek megfelelően tegenerálja i-edík adatforrásként az azonosítóját (afiid) és titkosító kulcsát (af.i.enc), melyeket a kérelmezőnek átad. Saját titkos kulcspárja segítségével (reg.enc) tegenerálja a titkosító kulcshoz tartozó osztályozó kulcsot (ak.oszt.i.enc(x)“reg.enc(af.i..dec(x))) és az első jelentő kulcsot (ak.repJ.encX melyeket az azonosítóval (af.i.id) átad az adatkezelőnek. Adatkezelő a jelentő kulcsot (ak.rep.i.enc) saját maga rendszeresen módosítja Az osztályozó kulcs átadása védett kriptoprocesszorban történik, hogy az osztályozó kulcsot képző kompozíciót alkotó első függvény (af.i.dec) eredményét az adatkezelő ne ismerhesse meg és így ne kaphasson vissza nyílt adatot. Adatkezelő számára az adatforrás személye titokban marad.
Ekkor az i-edik adatforrásként regisztrált biztosító készen van az adatok rendszerbe töltésére. Megkötött szerződéseiből összeállít egy olyan táblázatot, melyben a fent definiált ingatíanazonosító, a kedvezményezett ügyfél azonosítója, a fedezett kárösszeg és a két dátum, azaz a kockázatviselés kezdete és vége szerepel, illetve egy logikai érték, melynek igaz értéke azt jelöli, hogy csak ajánlatkérés .adatairól van szó. Ha egy szerződésben több kedvezményezett szerepel, úgy mindegyik a táblázat külön sorába kerül. Ezt követően a biztosító az ingatlan és az ügyfél azonosítókat leképezi a saját titkosító kulcsával (af.i.enc), melyekre a táblázatban szereplő azonosítókat kicseréli, és az anonimitását megőrző eljárással soronként átadja a táblázatot az adatkezelőnek. Az egyszerűség kedvéért: erre a célra használjunk egy az adatkezelő által felügyelt postaládát, melyben az adatkezelő előre elhelyez egy általa hitelesen aláírt tranzakció azonosítót, melynek másolata nála is megvan. Amikor az adatforrás elhelyezi az adatot a postaládában, kiveszi a tranzakció azonosítót, melyet megőriz. Az adatkezelő tehát „talál a postaládájában” egy anonim azonosítót (af.Lid) és a fenti táblázat egy sorát, melyben az ingatlant és a biztosítások egyik kedvezményezettjét titkosított azonosító jelöli. Ezeket a titkosított azonosítókat az anonim azonosítóhoz tartozó osztályozó függvénnyel (ak.oszt.í.enc) leképezi, a visszaigazolásban lévő tranzakció azonosítót a táblázat új oszlopaként hozzárendeli, majd ezekkel az értékekkel a sorokat az adattárba írja. Ezzel egy olyan adattárat épít, melyben
- nem tudja, hogy melyik adatnak ki a forrása,
- nem tudja sem az ingatlanokat, sem a kedvezményezetteket azonosítani, - az adattár elleni anonimitás feltörési támadás esetén sem az ingatlanok, sem a kedvezményezettek anonimitását nem tudja feltörni sem bármelyik adatforrás (a saját maga által szolgáltatott adat kivételével, mert azt a tranzakció azonosító alapján saját adatbázisában megtalálja), sem kívülálló személy, az adatkezelővel együttműködve sem.
A rendszer további használata során számos, az anonimitást biztosító elektronikus kommunikációs módszerek valamelyikét használjuk,, vagy az itt említett postafiókot, A rendszert az adatszolgáltató társaságok azért hozzák létre, hogy a biztosítási szerződést kötő ügyfelek deviáns viselkedését az újabb biztosítás megkötése előtt felismerjék. Ehhez lekérdezést kell indítaniuk. Az ajánlatot kérő ügyfél által megadott adatokból kell összeállítani a lekérdezést. Legyen most ez az ingatlan azonosító és az ügyfél azonosító. Példánkban a biztosító tudni akarja, hogy az ingatlanra milyen biztosítások vannak nyilvántartva a rendszerben. A biztosító számára az is fontos kockázatbecslési információ lehet, ha az ügyfél más ingatlanra, is rendelkezik aktív biztosítással. Az pedig különösen fontos lehet, ha ezekben a biztosításokban ugyanazok az ügyfelek egyszerre tűnnek fel· A lekérdezés két paraméterét a biztosító saját titkosító kulcsával (af.l.enc) leképezve az adatkezelőnek az anonim kommunikációs csatornán ugyanolyan protokollal adja át, mint ahogy az adatszolgáltatás történik, azaz a lekérdezéshez is tartozni fog előnyösen egy hiteles visszaigazolásra írt tranzakció (azaz lekérdezés) azonosító. Természetesen a lekérdezésben sem tudja személyhez kapcsolni sem a paramétereket, sem a lekérdezőt az adatkezelő. Az ügyfélre és az ingatlanra vonatkozó, korábbi adatszolgáltatásakor kapott hitelesített tranzakció azonosítókat is mellékelheti a lekérdező. Az adatkezelő az osztályozó kulccsal (ak.osztJ.enc) leképezi a titkosított ingatlanés ügyfél azonosítói, majd ezen értékek alapján az adattárban megkeresi az ügyfél biztosításait, illetve az ingatlanra vonatkozó más biztosításokat. Ez azért lehetséges, mert az adatszolgáltatáskor is ugyanazon értékekre történt az osztályozó leképezés, mint most a paraméterek esetében. A keresés beállítható úgy is, hogy azon ügyfelek és ingatlanok is kerüljenek be a jelentésbe, melyek adott számú hálózati kapcsolatnál közelebb vannak a paraméterekben átadott vagy a visszaigazolásokban érintett entitásokhoz. így azok az ingatlanok is megjelennek az eredményben, melyekre olyan ügyfelek kötöttek biztosítást, akikkel az adott ügyfélnek más ingatlan(ok)ra biztosítása van. így a biztosítási ajánlatot kérő ügyfélhez és az adott ingatlanhoz kapcsolódó ingatlanbiztosítási szerződések hálózata lesz elemezhető. Az adatkezelő az adatokat olyan táblázatba rendezi, mely megfelel a tárolásakor létrehozottnak, azaz az összes tranzakció azonosító ott lesz a sorok végén. Az ingatlan és ügyfél azonosítók a jelentő függvénnyel (ak.rep.i.enc) leképezésre kerülnek. A lekérdezés eredményét egy postaládába helyezi az adatkezelő és a postaládára kívülről ráírja a lekérdezés azonosítóját. Ha a lekérdező meglátja az azonosítót, bemutatja az adatkezelőnek a lekérdezés paramétereinek átadásakor kapott hiteles visszaigazolást, majd kiveszi az eredményt.
A biztosító a leképezés eredményében egy táblázatot (ingatlan, kedvezményezett, biztosítás kezdete és vége, összeg) iát, melyben a két entitás
- 22 azonosító (ingatlan, ügyfél) bijektíven leképezett anonim azonosítóként szerepei. Az átadott tranzakció azonosítók minden sor mellett feltüntetésre kerülnek, így a saját forrású adatok esetében a biztosító, saját adatainak használatával az anonimitást képes feltörni. Ehhez az is szükséges, hogy saját adatbázisában tárolja el a szolgáltatott adatokra kapott tranzakció azonosítót. A biztosító azonban nem látja a más biztosítótól származó ingatlanok és ügyfelek nyílt azonosítóit és azokat az adatokat, melyek az ügyféltől vagy az ingatlantól adott hálózati távolságnál messzebb vannak.
Tegyük fel hogy a lekérdezés eredményében a biztosító olyan deviáns szerződés portfoliót detektált. mely indokolja, hogy további adatokhozjusson. Fel kell tehát vennie a kapcsolatot a vizsgálni kívánt tranzakciók adatforrásaival. Ez egy konkrét tranzakció esetén a fentiek szerinti lépésekkel történik . A lekérdező választ egy postaládát, amely az adatkezelő felügyelete alatt van (igényel egy üres postaládát). Tegyük fel, hogy az adatforrások ismernek egy szimmetrikus kulcsú kriptográfiai leképezést (f), melyet erre a célra fognak használni, tehát csak a közös kulcsban kell megállapodni. A Diffie-Hellmann kulcscsere algoritmust éppen erre találták ki, hiszen ott az anonimitás megmarad. Sajnos ekkor az adatkezelő könnyedén kivitelezhet egy közbeékelödéses támadást (man-in-the-middle attack), mivel a postafiókot maga felügyeli. A nyilvános kulcsok használata azért nem jöhet szóba, mert a felek nem ismerik egymást. Ezért valamely kriptográfiai algoritmus kulcsaként olyan információt kell használni, mellyel mindketten eleve rendelkeznek, de az adatkezelő nem. A lekérdező valamely általa ismert ügyfélhez és/vagy ingatlanhoz kapcsolódó tranzakciókra, illetve az azokhoz hálózatosán kapcsolódó más tranzakciókra keres adatot. így a lekérdezés eredményében kapott tranzakciók között kell tennie olyannak, amelyben az általa keresett ügyfél vagy ingatlan közvetlenül szerepei. Ezen tranzakció nyílt adatait az adatforrás értelemszerűen ismeri, hiszen tőle származik, az adatkezelő viszont soha nem iát nyílt entitásazonosítót. így a lekérdező a találatok között keres egy tranzakciót, melyről azt feltételezi, hogy valamelyik entitás (pl. ügyfél, ingatlan) közvetlenül érintett benne (ennek nyílt azonosítója: eJd). Az entitás nyílt azonosítóját kulcsként használva titkosítja a tranzakció azonosítót (c ~ f(a.íd, tr.id), ahol az első paraméter az
-23alkalmazott kulcs). Ezt az értéket (c) beletesz! a postaládába, majd láthatóan felrakja címkének a nyílt tranzakció azonosítót és saját lekérdezés azonosítóját, így a felek anonimitásukat megőrizve tudják igazolni, a hiteles visszaigazolásaik bemutatásával adatkezelő előtt, hogy jogosultak hozzáférni a postaláda tartalmához. Ha egy adatforrás látja, hogy egy nála lévő visszaigazolás! címkével nyílt egy postaláda, azaz: tőle származó adatra vonatkozó információt kér valaki, úgy az adatkezelőnek bemutatja az arra vonatkozó hiteles visszaigazolást, és kiveszi a postaláda tartalmát. A tranzakcióban szereplő kulcsok mindegyikével megpróbálja dekódolni az üzenetet. Ha valamelyik esetében a leképezés működik (azaz tmdMfe.M c) igaz), úgy ezt a. kulcsot (e.id) használhatják kommunikációra. Az adatforrás a kulcsot úgy erősíti meg a lekérdező számára, hogy a lekérdezés azonosítót rejtjelezve elküldi neki. Sajnos jelentős probléma, hogy a szóba jöhető entitások száma a kriptográfiában igényelt sokasághoz képest elenyészően kicsi. így ezt a kulcsot csak a Diffie-Hellman kulcscseréhez szükséges két üzenetváltáshoz használják, kellően gyors üzenetváltással megakadályozva, hogy az adatkezelő közbeékelődéses támadást (man-ín-themiddle attack) hajtson végre. Ezt követően ezt az új, erős kriptográfiai kulcsot használják a további kommunikációban. Ekkor akár arról is biztonságosan megállapodhatnak, hogy az itt leírt módszertől függetlenül, akár közvetlenül vegyék fel egymással a kapcsolatot. így az. üzenetek tartalmának esetleges későbbi feltörése csupán a kapcsolatfelvételhez szükséges elévült információt fedi fel. A továbbiakban a lekérdező pontosan specifikálhatja, hogy mire van szüksége, adatforrás pedig indoklást kérhet a lekérdezés indokoltságára, kérheti az üggyel kapcsolatos információk kölcsönös kicserélését. Saját döntésük alapján fel is adhatják egymás előtt anonimitásukat, és így már az itt leírt rendszeren kívül, közvetlenül is együttműködhetnek.
A bevezetőben megfogalmazott követelményeket a találmánnyal kielégítettük: létrehoztunk egy anonim, de elemzésre alkalmas adattárat. A lekérdező és az adatforrás között titkosított adatcsatorna hozható létre, ahol saját, egyedi döntésük alapján bővíthetik együttműködésüket, saját anonimitásuk megőrzése mellett, de akár azt önként feladva közvetlenül, a rendszer keretein kívül is kapcsolatba is léphetnek egymással.
- 24 A találmányhoz fűződő - a technika állásához viszonyított előnyös hatások a következők:
A találmány szerint olyan anonim adattárat hozunk létre, ahol
- a központi, adatkezelő funkciókat ellátó személy vagy szervezet számára az adatokban reprezentált entitások anonimek maradnak,
- az adatforrások és lekérdezők anonimek maradnak, és
- a lekérdezések eredménye anonim, de a saját forrású adatok egy tranzakció azonosító használatával nyílt adathoz rendelhetőek,
- az entitások nyílt és anonim azonosítói között bijektiv a kapcsolat, mely garantálja, hogy az anonim, de egyedi azonosítóval ellátóit entitások között meglévő kapcsolatok topológiaiig egyenértékű hálózatot hozzanak létre, és
- a lekérdező és az adatforrás privát anonim adatcsatornát hozhat létre, a közbeékelödéses támadás ellen védett módszerrel.
A lekérdezések eredményében a lekérdező egyedileg látja az entitásokat, és az eredetivel megegyező struktúrában a köztük lévő kapcsolatokat. Korlátozni lehet a lekérdezési hatáskört olyan találati halmazra, melyben valamennyi adat adott kapcsolati távolságnál közelebb van olyan adathoz, melyet a lekérdező korábban maga szolgáltatott. Ezt a lekérdező előnyösen a (hiteles) visszaigazolás vagy tranzakció azonosító bemutatásával igazolja. A lekérdezések eredményében az entitás-azonosítók minden felhasználó esetén egyediek.
Senki nem rendelkezik egyedül olyan leképezéssel mely az anonim adattárból nyílt entitás-azonosítót ad, sőt a szereplők együttesen sem képesek ilyen műveletet a konkrét adat forrásának közreműködése nélkül végrehajtani.
A rendszert használók előnyösen korlátozva vannak abban, hogy a teljes adattárat elemezhessék, mivel olyan adatra épülő részhálózathozjuthatnakcsak hozzá, melyre vonatkozóan az adatforrásnak küldött hiteles visszaigazolást be tudják mutatni. A lekérdezés eredményét olyan feltétetek figyelembevételével is
- 25 elő lehet állítani, hogy különösen jellegzetes tulajdonságú csomópont vagy részgráf ne legyen benne. Ezzel a skálaföggetlen gráfok esetében is jelentősen növelhető az anonimitás védelme, az elemezhetőség fenntartása mellett.
A találmány szerinti anonim adatmegosztó informatikai megoldás anonim adatforrások egymástól védett adatainak kölcsönös elemzését teszi lehetővé az adatentitások egyetemes egyediségének megőrzésével. A találmány általánosan összefoglalva a következő fő és előnyös jellemzőkel rendelkezik.
- (regisztráció) az adatforrások egy vagy több független szolgáltatónál (regisztrátor) regisztrálnak a rendszer használatához, mely folyamat során a regisztrálót legenerálja az adatszolgáltató egyedi, anonim azonosító kódját és a következő kriptográfiai kulcsokat: az adatforrás saját titkosító kulcsát, az ehhez tartozó osztályozó kulcsot és a jelentő kulcsot, melyek közül az adatforrásnak az anonim azonosítót és a saját titkosító kulcsot, az adatkezelőnek pedig az anonim azonosítót, az osztályozó kulcsot és a jelentő kulcsot átadja, ahol (leképezések) az adatforrások saját titkosító függvénye egy elegendően erős kriptográfiai leképezés; a titkosító leképezés és a hozzá tartozó osztályozó leképezés függvény-kompozíciója elegendően erős kriptográfiai függvény azzal kiegészítve, hogy valamennyi ilyen leképezés-kompozíció azonosan egyenlő a teljes értékkészletre, azaz minden függvénykompozíció azonos titkosított értékre képezi a nyílt entitás-azonosítót; a jelentőfüggvény egy erős kriptográfiai leképezés, melynek értelmezési tartományának részhalmaza az osztályozó függvény értékkészlete; a leképezések végrehajtása során nyílt adat nem keletkezik;
- (küldendő adat) az adatforrás saját adatai entitás-azonosítóval reprezentált entitások közötti relációkból és e relációkat jellemző adatokból állnak, melyeket saját azonosító kódjával együtt, úgy küld el az adatkezelőnek, hogy az entitás-azonosítókat saját leképezésével titkosítja, amit
- (visszaigazolás és tárolás) az adatkezelő az azonosító kódhoz tartozó osztályozó függvénnyel leképezve adattárba ír egy saját maga által képzelt,
- 26 egyedi tranzakció azonosítóhoz rendelve, mely azonosítót hitelesen aláírva átad az adatforrásnak, (lekérdezés)
- lekérdezést az adatforrás az adatkezelőnél úgy kezdeményez, hogy elküldi az azonosítóját, opcionálisan az eredményben vélhetően szereplő tranzakciókra vonatkozó hitelesített visszaigazolásokat és más, a lekérdezés hatókörét érintő paramétereket, köztük az entitás-azonosító paramétereket saját titkosító függvényével leképezve,
- a lekérdezésről, előnyösen ugyanolyan bizonyító erejű visszaigazolást kap, mint az adatszolgáltatásról;
- a titkosított entitás-azonosító paramétereket adatkezelő a lekérdező azonosítójához tartozó osztályozó függvénnyel leképezi, majd végrehajtja az adattárban a keresést ügy, hogy opcionálisan azokat az adatelemeket veszi figyelembe, melyek egy adott hálózati távolságon beiül vannak az átadott visszaigazolásokban szereplő tranzakció azonosítókban szereplő bármelyik adatelemtől;
- az eredményben a visszaigazolásokban átadott tranzakció azonosítók vagy opcionálisan valamennyi tranzakció azonosító megjelenhet, hogy saját adatainak használatával vagy opcionálisan egy másik adatforrás önkéntes közreműködésével a lekérdező nyílt entitás-azonosítókat és további adatokat kaphasson;
(eredmény) az entitás-azonosítókat az adatkezelő a lekérdezőhöz tartozó jelentő függvénnyel képezi le, majd adja át neki.
(kommunikáció) az adatforrások/lekérdezők és az adatkezelő közötti kommunikáció az adatforrás/lekérdező anonimitását védő adatcsatornán folyik.
A találmány olyan adatgyűjtő és lekérdező rendszert eredményez, melyben a tárolt entitások anonimitása megmarad úgy, hogy az egyes szereplőknek nem kell megbízniuk egymásban, miközben a lekérdezések eredményeként az
- zu entitások közti relációk megmaradnak. Az adatforrások elemzési képessége úgy is korlátozható, hogy csak az általuk szolgáltatott adattól bizonyos hálózati távolságra lévő adatelemeket érhessék el, miközben a felépített adattár anonim.
A leírt módszer opcionálisan arra is lehetőséget ad, hogy az adatforrás és a lekérdező privát kommunikációt folytasson egymással, miközben anonimitásuk saját döntésüktől függően megmaradhat. így önkéntes döntésük alapján akár nyílt adatot is megoszthatnak egymással.
A találmány szerinti eljárásban résztvevő főbb informatikai eszközök és főbb komponenseik bármilyen szokásos kialakításúak lehetnek. Az eszközök lehetnek szoftveres eszközök, hardveres eszközök vagy ezek kombinációi. A hardveres eszközök bármilyen alkalmas felhasználói eszközök lehetnek, és tipikusan egy vagy több processzorral, adattárolóval, kommunikációs egységgel és perifériákkal rendelkeznek. Az eszköz lehet például szerver, asztali számítógép, laptop, notebook, mobiltelefon, különösen okostelefon, táblagép, stb. Felhő alapú implementáció is lehetséges. A találmány szerinti eljárási lépéseket megvalósíthatják szoftveres vagy hardveres eszközök vagy ezek kombinációja. Szoftveres megvalósítás esetén az egyes eljárási lépéseket megvalósító eszközök tipikusan program-modulok. Ha az osztályozó leképezés eredményének kiszámításakor szükség van az adatforrás titkosító függvénye inverzének végrehajtására, úgy ezt a leképezést előnyösen javasolt biztonságos kriptoprocesszorral végrehajtani, így ilyenkor ez a hardver eszköz is a rendszer része
A kommunikációs csatornák létesíthetők például valamely elektronikus kommunikációs hálózat keretien beiül ami lehet például vezetékes és/vagy vezeték nélküli helyi informatikai hálózat (LAN), Wifl, vagy globális informatikai hálózat, különösen Internet, továbbá 3G vagy 4G szabvány szerinti mobil telekommunikációs hálózat, GSM hálózat, stb.
A 12 adatbázist az 1. ábrán a 11 adatkezelő integrált részeként tüntettük fel, azonban 12 adatbázis alatt külső adattároló eszközt is értünk. A 12 adatbázis tetszőleges elektronikus, mágneses, optikai vagy bármilyen más elven működő adattároló eszköz lehet (például memória,, memóriakártya, merevlemez, külső lemez, felhő alapú tárhely; stb.)

Claims (4)

29Szabadalmi igénypontok
1. Adatkezelő eljárás anonim adatmegosztő rendszerhez, amelynek során
- adatforrástól (10) adatszolgáltatást veszünk, amely adatszolgáltatás tartalmaz
- anonim adatforrás azonosítót,
- az adatforrás (10) saját titkosító kulcsával titkosított entitásazonosítót és
- az entitáshoz tartozó adatot, azzal jellemezve, hogy
- egy az adatforrás azonosítóhoz tartozó osztályozó kulccsal a titkosított entitás-azonosítót közös anonim entitás-azonosítóra leképezzük oly módon, hogy minden entitás-azonositóra teljesül, hogy azt bármely adatforrás (10) saját titkosító kulcsával titkosítva és az adatforrás azonosítójához tartozó osztályozó kulccsal leképezve ugyanazon közös anonim entitás-azonosítót kapjuk, és
- az entitáshoz tartozó adatot a közös anonim entitás-azonosítóhoz rendelten adatbázisban (12) eltároljuk.
2. Az 1. igénypont szerinti eljárás, azzal jellemezve, hogy
- adatforrástól (10) entitásra kiterjedő lekérdezést veszünk, amely lekérdezés tartalmaz · ·· anonim adatforrás azonosítót és
- az adatforrás (10) saját titkosító kulcsával titkosított, entitásazonosítót,
- és az adatforrás azonosítóhoz tartozó osztályozó kulccsal a titkosított entitás-azonosítót a közös anonim entitás-azonosítóra leképezzük, a lekérdezés eredményét összeállítjuk, majd a lekérdezés eredményében a közös anonim entitás-azonosítót egy az adatforrás azonosítóhoz tartozó jelentő kulccsal titkosítják és a lekérdezés eredményét ezt kővetően továbbítjuk a lekérdező adatforráshoz (10).
3. A 2. igénypont szerinti eljárás, azzal jellemezve, hogy
- 30 az adattároláshoz tranzakció azonosítót generálunk, amelyet az adatbázisban (12) eltárolt adatokhoz rendelten eltárolónk, és a tranzakció azonosítót az adatforrásnak (10) visszaigazolásban megküldjük, továbbá
- a lekérdezés paraméterként tartalmaz
- tranzakció azonosítót is,
- és a lekérdezés eredményébe csak olyan adatokat foglalunk, amelyek a tranzakció azonosítóval kapcsolatban vannak.
4 A 3. igénypont szerinti eljárás, azzal jellemezve, hogy a tranzakció azonosítót az adatforrásnak (10) hitelesen aláírva küldjük meg a visszaigazolásban.
5. A 3. vagy 4. igénypont szerinti eljárás, azzal jellemezve, hogy a lekérdezés eredményébe a tranzakció azonosítókat is belefoglaljuk,
6. Regisztrációs eljárás a 2. igénypont szerinti, adatkezelőben (11) megvalósított adatkezelő eljáráshoz, amelynek során egy vagy több független regisztrátornál (13) az adatforrások (10) regisztrációját valósítjuk meg, azzal jellemezve, hogy a regisztrálónál (13) generáljuk ~ az adatforrás (10) anonim azonosítóját, valamint ahhoz tartozóan
- az adatforrás (10) saját titkosító kulcsát,
- az osztályozó kulcsot és
- a jelentő kulcsot melyek közül az adatforrásnak (10) az anonim azonosítót és a saját titkosító kulcsot, az adatkezelőnek (11) pedig az anonim azonosítót, az osztályozó kulcsot és a jelentő kulcsot átadjuk,
7. A 6, igénypont szerinti eljárás, azzal jellemezve, hogy a jelentő kulcsot a regísztrátorraí (13) vagy az adatkezelés keretében képezzük, és az adott adatforráshoz tartozó jelentő kulcsot időnként lecseréljük,
8. A 6. vagy 7. igénypont szerinti eljárás, azzal jellemezve,, hogy a kulcsokat az RSA szabvány szerint a következő módon képezzük:
- az RSA szerinti inverz kulcsok, az adatforrás (10) titkosító kulcsa inverzének (afj.dec) kivételével nem kerülnek iegenerálásra,
- a kulcsok generálásáért felelős regisztrátor (13) rendelkezik egy saját kriptográfia kulccsal (reg.enc), a regisztrátor (13) megképzi a kérelmező adatforrás (10) saját titkosító (af.i.enc) kulcsát és annak inverzét (af.i.dec). és a jelentő kulcsot (ak.rep.i..enc),
- az osztályozó kulcs (ak.osztlenc) az adatforrás (10) titkosító kulcsának inverzével (afJ.dec), majd a regisztrátor (13) saját kulcsával (reg.enc) ebben a sorrendben végrehajtott leképezés (ak. oszt. i .enc(c)=reg .enc(af Idecíc))).
9. A 8. igénypont szerinti eljárás, azzal jellemezve, hogy az osztályozó kulcs (ak.osztJ.enc), biztonságos kriptoprocesszorba Írva kerül az adatkezelőnek (11) átadásra.
10 Az 5-9. igénypontok bármelyike szerinti eljárás, azzal jellemezve, hogy a lekérdező adatforrással (10) a lekérdezés eredményének ismeretében anonimitást védő titkos adatcsatorna létrehozását kezdeményezzük egy másik adatforrással (10) a következő módon:
- az adatkezelővel (11) az adatforrások (10) számára elérhetővé teszünk egy adattárolásra alkalmas eszközt, előnyösen elektronikus postaládát, amely minden adatforrás (10) számára látható két tranzakció azonosítóval jelölhető meg.,
- a rendszer használói ismernek egy szimmetrikus rejtjelező algoritmust (f),
- a lekérdező adatforrás (10) a lekérdezés eredményéből kiválasztott tranzakcióhoz szerinte tartozó entitás vagy entitások nyílt azonosítóját (e.id) használva rejtjelezi a tranzakció azonosítót (c-fCo.idJr.id), ahol az első paraméter az. alkalmazott kulcs), azt postaládában elhelyezi, melyre kívülről címkeként ráírja a nyílt tranzakció azonosítót és a lekérdezés nyílt azonosítóját,
- a továbbiakban a postaiadéhoz az anonim felek a címkéhez tartozó hiteles tranzakciós és lekérdezési visszaigazolások adatkezelőnek történő bemutatásával férhetnek hozzá,
- az adatkezelő (11) közzéteszi az adatforrások (10) között az adatkérés tárgyát képező tranzakció azonosítóját azért, hogy a tranzakcióhoz tartozó másik adatforrás (10) lássa a tőle származó tranzakcióra vonatkozó adatkérést és így hozzájusson a postaláda tartalmához (c), majd a másik adatforrás (10) a tranzakcióhoz tartozó entításazonosítók közöl megkeresi azt, amely nyílt adatként a tranzakció azonosítót adja vissza (melyre tdd~f(eJd ,c) igaz), majd ~ a másik adatforrás (10) ugyanezt a postaládát és rejtjelkulcsot használva a postaládán látott lekérdező azonosítót elküldi a lekérdező adatforrásnak (10), a közös kulcsot így visszaigazolva,
- a felek e kriptográfiai leképezést csak egy Diffie-Hellman kulcscserélő algoritmushoz szükséges két üzenetváltáshoz használják így megakadályozva, hogy az adatkezelő (11) közbeékelődéses támadást hajtson végre, majd ezt az adatcsatornát használva a lekérdező adatforrás (10) és a másik adatforrás (10) között rejtjelezett kommunikációt folytatunk.
11. Adatkezelő (11), anonim adatmegos^ó rendszerben való alkalmazáshoz, amely adatkezelő (11) tartalmaz
- adatvételi eszközt, adatforrástól (10) érkező adatszolgáltatás vételére, amely adatszolgáltatás tartalmaz · ·· anonim adatforrás azonosítót,
- az adatforrás (10) saját titkosító kulcsával titkosított entitásazonosítót és
- az entitáshoz tartozó adatot, azzal jellemezve. hogy tartalmaz továbbá leképező eszközt egy az adatforrás azonosítóhoz tartozó osztályozó kulccsal a titkosított entitás-azonosítónak közös anonim entitás azonosítóra történő leképezésére oly módon, hogy minden entitás azonosítóra teljesül· hogy bármely adatforrás (10) saját titkosító kulcsával titkosítva és az adatforrás azonosítójához tartozó osztályozó kulccsal leképezve ugyanazon közös anonim entitás··azonosítót eredményez, és
- eltároló eszközt az entitáshoz tartozó adatnak a közös anonim entitásazonosítóhoz rendelten, adatbázisban (12) való eltárolására.
12. A 11. igénypont szerinti adatkezelő, azzal jellemezve, hogy tartalmaz
- lekérdezés-vételi eszközt, adatforrástól (10) entitásra kiterjedő lekérdezés vételére, amely lekérdezés tartalmaz
- anonim adatforrás azonosítót és
- az adatforrás (10) saját titkosító kulcsával titkosított entitásazonosítót,
- leképező eszközt az adatforrás azonosítóhoz tartozó osztályozó kulccsal a titkosított entitás-azonosítónak a közös anonim entitásazonosítóra történő leképezésére, · ·· a lekérdezés eredményét összeállító eszközt, · ·· a lekérdezés eredményében a közös anonim entitás-azonosítót egy az adatforrás azonosítóhoz tartozó jelentő kulccsal titkosító eszközt, valamint
- a lekérdezés eredményét a lekérdező adatforráshoz (10) továbbitó eszközt.
13. A 12. igénypont szerinti adatkezelő, azzal jellemezve, hogy tartalmaz
- az adattároláshoz tranzakció azonosítót generáló eszközt,
- a. tranzakció azonosítót az adatbázisban (12) eltárolt adatokhoz rendelten eltároló eszközt és
- a tranzakció azonosítót az adatforrásnak (10) visszaigazolásban megküldő eszközt, továbbá
- a lekérdezés tartalmaz.
- tranzakció azonosítót is,
- és az adatkezelőnek (11) a lekérdezés eredményébe csak a tranzakció azonosítóval kapcsolatban lévő adatokat foglaló, lekérdezés eredményét összeállító eszköze van,
14. A 13. igénypont szerinti adatkezelő, azzal jellemezve, hogy a tranzakció azonosítót az adatforrásnak (10) a visszaigazolásban hitelesen aláírva megküldő eszköze van, valamint a lekérdezés eredményébe a tranzakció azonosítókat is belefoglaló, lekérdezés eredményét összeállító eszköze van.
15. Anonim adatmegosztó rendszer, azzal jellemezve, hogy a 11-14, igénypontok bármelyike szerinti adatkezelőt (11) tartalmaz.
(4 lap rajz, 6 ábra)
HU1600099A 2016-02-18 2016-02-18 Adatkezelő eljárás és regisztrációs eljárás anonim adatmegosztó rendszerhez, valamint adatkezelő és azt tartalmazó anonim adatmegosztó rendszer HU231270B1 (hu)

Priority Applications (3)

Application Number Priority Date Filing Date Title
HU1600099A HU231270B1 (hu) 2016-02-18 2016-02-18 Adatkezelő eljárás és regisztrációs eljárás anonim adatmegosztó rendszerhez, valamint adatkezelő és azt tartalmazó anonim adatmegosztó rendszer
PCT/HU2017/000012 WO2017141065A1 (en) 2016-02-18 2017-02-17 Data management method and registration method for an anonymous data sharing system, as well as data manager and anonymous data sharing system
US16/306,709 US11263344B2 (en) 2016-02-18 2017-02-17 Data management method and registration method for an anonymous data sharing system, as well as data manager and anonymous data sharing system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
HU1600099A HU231270B1 (hu) 2016-02-18 2016-02-18 Adatkezelő eljárás és regisztrációs eljárás anonim adatmegosztó rendszerhez, valamint adatkezelő és azt tartalmazó anonim adatmegosztó rendszer

Publications (2)

Publication Number Publication Date
HUP1600099A2 HUP1600099A2 (hu) 2017-08-28
HU231270B1 true HU231270B1 (hu) 2022-07-28

Family

ID=89992084

Family Applications (1)

Application Number Title Priority Date Filing Date
HU1600099A HU231270B1 (hu) 2016-02-18 2016-02-18 Adatkezelő eljárás és regisztrációs eljárás anonim adatmegosztó rendszerhez, valamint adatkezelő és azt tartalmazó anonim adatmegosztó rendszer

Country Status (3)

Country Link
US (1) US11263344B2 (hu)
HU (1) HU231270B1 (hu)
WO (1) WO2017141065A1 (hu)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9704316B2 (en) 2013-09-10 2017-07-11 Gregory Paul Kirkjan Contactless electronic access control system
US11012428B1 (en) * 2017-03-02 2021-05-18 Apple Inc. Cloud messaging system
US11165771B2 (en) 2017-11-20 2021-11-02 At&T Intellectual Property I, L.P. Proximity based data access restrictions
EP3752949A4 (en) * 2018-02-12 2021-11-10 Equifax, Inc. FACILITATION OF ENTITY RESOLUTION VIA A RESOLUTION DATABASE OF A SECURE ENTITY
US10997403B1 (en) 2018-12-19 2021-05-04 First American Financial Corporation System and method for automated selection of best description from descriptions extracted from a plurality of data sources using numeric comparison and textual centrality measure
US11048711B1 (en) * 2018-12-19 2021-06-29 First American Financial Corporation System and method for automated classification of structured property description extracted from data source using numeric representation and keyword search
HUP1900254A1 (hu) * 2019-07-15 2021-01-28 Xtendr Zrt Kriptográfiai álnév leképezõ eljárás és számítógépes rendszer, valamint számítógépes program és számítógéppel olvasható adathordozó
HUP1900255A1 (hu) * 2019-07-15 2021-01-28 Xtendr Zrt Kriptográfiai álnév leképezõ eljárás és számítógépes rendszer, valamint számítógépes program és számítógéppel olvasható adathordozó
US11477014B1 (en) 2019-08-23 2022-10-18 Liberty Mutual Insurance Company Anonymized data transmission using per-user-functionality secret shares
CN114503105A (zh) * 2019-09-25 2022-05-13 联邦科学和工业研究组织 用于浏览器应用的密码服务
US11275851B2 (en) 2019-12-19 2022-03-15 Beijing Didi Infinity Technology And Development Co., Ltd. System, method, and storage medium for distributed data management
US11574513B2 (en) * 2020-03-31 2023-02-07 Lockfob, Llc Electronic access control
US11567932B2 (en) * 2020-10-26 2023-01-31 Oracle International Corporation Efficient compilation of graph queries on top of SQL based relational engine
US11507579B2 (en) 2020-10-26 2022-11-22 Oracle International Corporation Efficient compilation of graph queries involving long graph query patterns on top of SQL based relational engine
US11500868B2 (en) 2021-01-29 2022-11-15 Oracle International Corporation Efficient identification of vertices and edges for graph indexes in an RDBMS
US11494510B2 (en) * 2021-03-04 2022-11-08 Inmarket Media, Llc Multi-touch attribution and control group creation using private commutative encrypted match service
US11921785B2 (en) 2022-01-25 2024-03-05 Oracle International Corporation Inline graph algorithm execution with a relational SQL engine
CN115296936B (zh) * 2022-10-08 2023-08-01 四川安洵信息技术有限公司 一种反网络犯罪辅侦的自动化方法及系统

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4200770A (en) 1977-09-06 1980-04-29 Stanford University Cryptographic apparatus and method
US4405829A (en) 1977-12-14 1983-09-20 Massachusetts Institute Of Technology Cryptographic communications system and method
GB9920644D0 (en) 1999-09-02 1999-11-03 Medical Data Service Gmbh Novel method
US7519591B2 (en) 2003-03-12 2009-04-14 Siemens Medical Solutions Usa, Inc. Systems and methods for encryption-based de-identification of protected health information
JPWO2004084483A1 (ja) 2003-03-20 2006-06-29 株式会社日本医療データセンター 情報管理システム
US20060085454A1 (en) 2004-10-06 2006-04-20 Blegen John L Systems and methods to relate multiple unit level datasets without retention of unit identifiable information
US9355273B2 (en) 2006-12-18 2016-05-31 Bank Of America, N.A., As Collateral Agent System and method for the protection and de-identification of health care data
GB2469673A (en) 2009-04-23 2010-10-27 Sapior Ltd Encrypting data tags, metadata and labels in datasets to protect the identity of individuals when combining datasets or databases
WO2011039460A2 (fr) * 2009-09-30 2011-04-07 France Telecom Procede et dispositifs de communications securisees dans un reseau de telecommunications
DE102010037326B4 (de) 2010-09-03 2014-02-13 Wolfgang Hüffer Verfahren zum anonymen Zusammenführen von vertraulichen Daten und zugehörigen Identifizierungsdaten
US9202078B2 (en) * 2011-05-27 2015-12-01 International Business Machines Corporation Data perturbation and anonymization using one way hash
US8892685B1 (en) * 2012-04-27 2014-11-18 Google Inc. Quality score of content for a user associated with multiple devices
EP2926308B1 (en) * 2012-11-28 2019-07-17 Telefónica Germany GmbH & Co. OHG Method for anonymisation by transmitting data set between different entities
EP2926307B1 (en) 2012-11-28 2020-03-11 Telefónica Germany GmbH & Co. OHG Method for anonymisation by transmitting a data set between different entities
WO2018123190A1 (ja) * 2016-12-28 2018-07-05 ソニー株式会社 サーバ装置、情報管理方法、情報処理装置、情報処理方法およびプログラム

Also Published As

Publication number Publication date
US20190213356A1 (en) 2019-07-11
US11263344B2 (en) 2022-03-01
WO2017141065A1 (en) 2017-08-24
HUP1600099A2 (hu) 2017-08-28
WO2017141065A8 (en) 2018-01-04

Similar Documents

Publication Publication Date Title
HU231270B1 (hu) Adatkezelő eljárás és regisztrációs eljárás anonim adatmegosztó rendszerhez, valamint adatkezelő és azt tartalmazó anonim adatmegosztó rendszer
US8224979B2 (en) Use of proxy servers and pseudonymous transactions to maintain individual&#39;s privacy in the competitive business of maintaining personal history databases
US11240251B2 (en) Methods and systems for virtual file storage and encryption
US10341103B2 (en) Data analytics on encrypted data elements
Al Omar et al. A transparent and privacy-preserving healthcare platform with novel smart contract for smart cities
US9202079B2 (en) Privacy preserving data querying
Habegger et al. Personalization vs. privacy in big data analysis
Bräunlich et al. Linking loose ends: An interdisciplinary privacy and communication model
US11379616B2 (en) System and method for providing anonymous validation of a query among a plurality of nodes in a network
Praveena et al. A machine learning application for reducing the security risks in hybrid cloud networks
CN114981793A (zh) 模式的安全匹配和识别
El Haourani et al. Big Data security and privacy techniques
Kiyomoto et al. Fair-trading protocol for anonymised datasets requirements and solution
Parra-Arnau et al. Shall I post this now? Optimized, delay-based privacy protection in social networks
Tran A Systematic Literature Review on Secure IoT Data Sharing
Ekdahl et al. A Methodology to Validate Compliance to the GDPR
AU2021106598A4 (en) Blockchain based secure data exchange and analysis system for crowdsourcing
Preuveneers et al. Privacy-preserving correlation of cross-organizational cyber threat intelligence with private graph intersections
US11983284B2 (en) Consent management methods
US20230214398A1 (en) Data Privacy Management &amp; Compliance Using Distributed Ledger Technology
US20220229918A1 (en) Consent management methods
Pavithra et al. Enhanced Secure Big Data in Distributed Mobile Cloud Computing Using Fuzzy Encryption Model
Alarabi et al. Two Level Based Privacy Protection Approach for Internet of Things Users in Cloud Computing
US20220222373A1 (en) A Computer System and Method of Operating Same for Handling Anonymous Data
Amamou et al. Towards a Better Security in Public Cloud Computing

Legal Events

Date Code Title Description
GB9A Succession in title

Owner name: XTENDR ZRT., HU

Free format text: FORMER OWNER(S): VAGUJHELYI FERENC, HU; DR. MAGYAR GABOR, HU