Ανοικτή Διακυβέρνηση

25.1 Τοπολογία του συστήματος

Όσον αφορά στη γενική αρχιτεκτονική του συστήματος, αυτή συνδυάζει 5 διαφορετικά συστήματα, τα οποία αναφέρονται παρακάτω και αναλύονται στην παρούσα ενότητα. Τα κύρια συστήματα που απαρτίζουν τη συνολική αρχιτεκτονική είναι:

• Η διεπαφή παίκτη.
• Η πύλη ελέγχου σε πραγματικό χρόνο (Gateway).
• Η κεντρική πλατφόρμα παρόχου υπηρεσιών τυχερών παιγνίων.
• Το ενδιάμεσο σύστημα ελέγχου.
• Η υποδομή της Αρχής.

Σχηματικά, η τοπολογία του συστήματος παρουσιάζεται στην εικόνα που ακολουθεί.

Εικόνα 1. Τοπολογία τεχνικής λύσης

Ο πάροχος υπηρεσιών τυχερών παιγνίων μέσω διαδικτύου έχει την υποχρέωση να υλοποιήσει το ενδιάμεσο σύστημα ελέγχου και την πύλη ελέγχου σε πραγματικό χρόνο (Gateway), σύμφωνα με τις προδιαγραφές που παρουσιάζονται στη συνέχεια.

Το ενδιάμεσο σύστημα ελέγχου έχει σαν κύριες λειτουργίες τη συλλογή των δεδομένων από την κεντρική πλατφόρμα του παρόχου (data capture), την ασφάλεια των δεδομένων αυτών (ακεραιότητα, αυθεντικότητα, εμπιστευτικότητα, διαθεσιμότητα) (data sealing) και την οριστική αποθήκευσή τους στη διάταξη ασφαλούς αποθήκευσης (Safe).

Μέσω της πύλης ελέγχου σε πραγματικό χρόνο, όλη η διαδικτυακή κίνηση των παικτών κατευθύνεται στην κεντρική πλατφόρμα του παρόχου.

Η Αρχή έχει πρόσβαση στη διάταξη ασφαλούς αποθήκευσης, προκειμένου να προσπελάσει τα δομημένα σύνολα δεδομένων που απαιτούνται για τον ελεγκτικό και εποπτικό της ρόλο.

Στη συνέχεια περιγράφονται αναλυτικά οι τεχνικές προδιαγραφές των παραπάνω συστημάτων, δίνοντας μεγαλύτερη έμφαση στα υποσυστήματα του ενδιάμεσου συστήματος ελέγχου και στην πύλη ελέγχου σε πραγματικό χρόνο (Gateway).

25.2 Προέλευση δεδομένων (data capture)

Όπως έχει αναφερθεί, ο πάροχος έχει την υποχρέωση να υλοποιήσει στο ενδιάμεσο σύστημα ελέγχου, το υποσύστημα data capture, το οποίο εκτελεί τις παρακάτω λειτουργίες:

• Εξάγει δεδομένα από την κεντρική πλατφόρμα του παρόχου.
• Τα μετασχηματίζει στη μορφή που καλύπτει τις προδιαγραφές που τίθεται από την Αρχή (μοντέλα δεδομένων).
• Τα μεταφέρει προς αποθήκευση (αφού πρώτα εκτελέσει λειτουργίες για την ασφάλειά τους) στη διάταξη ασφαλούς αποθήκευσης (Safe).

25.2.1 Μορφή των δεδομένων

Η ενδεδειγμένη μορφή ανταλλαγής δεδομένων μεταξύ της Αρχής και παρόχου είναι η αποστολή δεδομένων μέσω αρχείων XML (eXtensible Markup Language). Η γλώσσα XML αποτελεί σήμερα ένα ευρέως διαδεδομένο και ανοικτό πρότυπο για την περιγραφή και ανταλλαγή δεδομένων. Η XML έχει αναπτυχθεί και συντηρείται από το W3C (World Wide Web Consortium).

Μέσω της χρήσης της γλώσσας XML για την ανταλλαγή των δεδομένων εξασφαλίζεται η ελεγχόμενη, ασφαλής και γρήγορη ροή δεδομένων, μεταξύ των δύο μερών. Ταυτόχρονα, η χρήση ενός διεθνούς και ανοικτού προτύπου, όπως η είναι η γλώσσα XML, συμβάλει στην ενίσχυση της διαλειτουργικότητας σε επίπεδο πληροφοριακών συστημάτων, μεταξύ κυβερνητικών οργανισμών και επιχειρήσεων, όπως περιγράφεται και στο Ελληνικό Πλαίσιο Παροχής Υπηρεσιών Ηλεκτρονικής Διακυβέρνησης (Greek eGIF).

Κατά το μετασχηματισμό των δεδομένων που εξάγονται από την κεντρική πλατφόρμα του παρόχου, ο πάροχος οφείλει να ακολουθεί τις οδηγίες που περιγράφονται στο εκάστοτε μοντέλο δεδομένων που ορίζει η Αρχή. Τα μοντέλα δεδομένων περιγράφονται από αντίστοιχα σχήματα XML (XML schemas). Πριν τα δεδομένα αποθηκευτούν και σφραγιστούν στη διάταξη ασφαλούς αποθήκευσης (Safe), πιστοποιούνται ως προς τη συμβατότητά τους με το μοντέλο δεδομένων, που ορίζει η Αρχή (validate XML against XSD). Τα αρχεία XSD θα είναι διαθέσιμα στους ενδιαφερόμενους μέσω του διαδικτυακού τόπου της Αρχής (https://www.gamingcommission.gov.gr).

Τα δεδομένα ακολουθούν την κωδικοποίηση UTF-8, ενώ όπου γίνεται αναφορά σε χρόνο, ακολουθείται το πρότυπο UTC.

25.2.2 Μέγιστη καθυστέρηση

Η μέγιστη καθυστέρηση μεταξύ του εκάστοτε γεγονότος και του χρόνου εισαγωγής του στο Safe είναι δύο (2) ώρες. Συνεπώς, τα δεδομένα πρέπει να μεταφέρονται στη διάταξη ασφαλούς αποθήκευσης (Safe) το αργότερο κάθε δύο (2) ώρες.

25.2.3 Χωροθέτηση υποσυστήματος data capture

Το υποσύστημα data capture μπορεί να φιλοξενείται εντός ΕΕ ή ΕΟΧ, αρκεί να πληρούνται οι προδιαγραφές που θέτει η Αρχή.

To data center που φιλοξενεί το υποσύστημα data sealing πρέπει να πληροί τις προδιαγραφές που περιγράφονται στο κεφάλαιο Ασφάλεια Υποδομών IT.

25.3 Κλείδωμα των δεδομένων (data sealing)

25.3.1 Διαδικασία κλειδώματος των δεδομένων

Στην ενότητα αυτή παρουσιάζεται αναλυτικά η διαδικασία κλειδώματος των δεδομένων, προκειμένου να διασφαλιστεί η ακεραιότητά και αυθεντικότητά τους. Ειδικότερα, η διαδικασία του κλειδώματος περιλαμβάνει μια σειρά βημάτων, τα οποία έχουν ως εξής:

• Βήμα 1: Δημιουργία πακέτων δεδομένων (batching) αποτελούμενων από έναν αριθμό εγγραφών, όπως περιγράφεται αναλυτικά στις ενότητες που ακολουθούν.
• Βήμα 2: Σύνδεση του τρέχοντος πακέτου δεδομένων με το αμέσως προηγούμενο (chaining), μέσω της συμπερίληψης στο τρέχον πακέτο μιας τιμής (SHA-256) του προηγούμενου πακέτου και δημιουργία μιας «αλυσίδας» πακέτων δεδομένων.
• Βήμα 3: Ψηφιακή υπογραφή των πακέτων δεδομένων.
• Βήμα 4: Συμπίεση δεδομένων με τον αλγόριθμο «deflate» (RFC1951).
• Βήμα 5: Χρονοσήμανση των συμπιεσμένων δεδομένων σύμφωνα με το πρότυπο XAdES-T.
• Βήμα 6: Τα συμπιεσμένα δεδομένα κρυπτογραφούνται με συμμετρικό, τυχαία παραγόμενο κλειδί, μιας χρήσης, της τρέχουσας συνόδου (AES-256).
• Βήμα 7: Το κλειδί συνόδου είναι κρυπτογραφημένο με το δημόσιο κλειδί της Αρχής (RSA-2048).
• Βήμα 8: Τα δεδομένα (από το βήμα 1.), η χρονοσήμανση (από το βήμα 5.) και το κρυπτογραφημένο κλειδί (από το βήμα 6.), δημιουργούν ένα νέο αρχείο zip, το οποίο αποθηκεύεται οριστικά στο Safe.

25.3.1.1 Batching – Πακέτα δεδομένων

Η μέγιστη καθυστέρηση μεταξύ του εκάστοτε γεγονότος και του χρόνου εισαγωγής του στο Safe είναι δύο (2) ώρες. Συνεπώς, τα δεδομένα πρέπει να μεταφέρονται στη διάταξη ασφαλούς αποθήκευσης (Safe) το αργότερο κάθε δύο (2) ώρες.

Τα δεδομένα εισάγονται στο Safe με τη μορφή πακέτων δεδομένων (batch). Σε κάθε πακέτο δεδομένων υπάρχει μόνο ένα αρχείο xml, για κάθε μοντέλο δεδομένων. Σε περίπτωση που πρέπει να αποσταλούν αρχεία xml που ανήκουν σε διαφορετικό μοντέλο δεδομένων, τότε δημιουργούνται τόσο πακέτα δεδομένων, όσα είναι και τα διαφορετικά μοντέλα δεδομένων. Το πακέτο δεδομένων φέρει ειδική χρονοσήμανση, όπως περιγράφεται στην παράγραφο 25.3.1.5.

Το πακέτο δεδομένων δημιουργείται στις ακόλουθες περιπτώσεις:

• Κάθε δύο (2) ώρες,
• ή όταν το μέγεθος της συμπιεσμένης πληροφορίας ξεπερνά τα 200MB,
• στο τέλος κάθε ημέρας (00:00 UTC).

Αν παρέλθει χρονικό διάστημα δύο (2) ωρών χωρίς να υπάρξει κάποια εγγραφή, τότε δημιουργείται ένα κενό πακέτο δεδομένων. Σε ένα κενό πακέτο δεδομένων δεν υπάρχει αρχείο δεδομένων xml, αλλά μόνο το αρχείο που περιέχουν τις πληροφορίες ελέγχου του συγκεκριμένου πακέτου.

25.3.1.2 Chaining

Προκειμένου να εξασφαλιστεί ο μέγιστος βαθμός ασφάλειας στην αποθήκευση και διατήρηση των δεδομένων στη διάταξη ασφαλούς αποθήκευσης δεδομένων, χρησιμοποιούνται τεχνικές σύνδεσης των διαδοχικών πακέτων δεδομένων (chaining), πριν αυτά αποθηκευτούν οριστικά σε αυτή.

Επιπλέον, η διαδικασία του chaining ενισχύει την ακεραιότητα και την αυθεντικότητα των καταγεγραμμένων δεδομένων, ενώ συνάμα εξασφαλίζει τη συνοχή τους.

Μέσω της διαδικασίας αυτής, η Αρχή είναι σε θέση να εντοπίσει τυχόν διαγραφή ή τροποποίηση των αρχειοθετημένων δεδομένων, ανεξάρτητα από το αν αυτό έχει γίνει από κακόβουλη ενέργεια ή όχι.

Μετά τη δημιουργία του τρέχοντος πακέτου δεδομένων, αυτό συνδέεται με το αμέσως προηγούμενο πακέτο δεδομένων, μέσω της συμπερίληψης μιας hash τιμής (SHA-256) στο τρέχον πακέτο (cryptographic linking). Ο τρόπος αναφοράς των τιμών hash των προηγούμενων πακέτων δημιουργεί μια «αλυσίδα» πακέτων δεδομένων, όπως παρουσιάζεται στην εικόνα που ακολουθεί.

Εικόνα 2. Διαδικασία σύνδεσης διαδοχικών πακέτων δεδομένων (chaining)

25.3.1.3 Ψηφιακή υπογραφή δεδομένων

Τα πακέτα δεδομένων που εισάγονται στο ασφαλές σύστημα αποθήκευσης πρέπει να φέρουν ψηφιακή υπογραφή, ώστε να διασφαλίζεται η ακεραιότητα και η αυθεντικότητά τους. Η ψηφιακή υπογραφή πρέπει να ακολουθεί το πρότυπο XAdES (ETSI TS 101 933), το οποίο είναι διεθνώς διαδεδομένο πρότυπο που χρησιμοποιείται για την ψηφιακή υπογραφή αρχείων τύπου XML.

Το πρότυπο XAdES ενσωματώνει επιπλέον χαρακτηριστικά ασφάλειας στις ψηφιακές υπογραφές, συνδυάζοντάς τις με χρονοσημάνσεις, ενώ υλοποιεί επίσης το κρυπτογραφικό “δέσιμο” της υπογραφής με μια πολιτική υπογραφής που εδραιώνει τη νομική της αξία, καλύπτοντας την απαίτηση για μη άρνηση της ευθύνης.

Κάθε πάροχος οφείλει να διαθέτει το δικό του κλειδί ψηφιακής υπογραφής.

25.3.1.4 Συμπίεση και Κρυπτογράφηση δεδομένων

Τα πακέτα δεδομένων συμπιέζονται με τον αλγόριθμο «deflate» (RFC1951), προκειμένου να μειωθεί ο όγκος των αποθηκευμένων δεδομένων στη διάταξη ασφαλούς αποθήκευσης (Safe).

Στη συνέχεια, το συμπιεσμένο πακέτο δεδομένων κρυπτογραφείται για να διασφαλιστεί η εμπιστευτικότητα χρησιμοποιώντας μια διαδικασία δύο βημάτων:

1. Αρχικά, η διάταξη ασφαλούς αποθήκευσης (Safe) θα πρέπει να δημιουργεί δυναμικά ένα συμμετρικό κλειδί (256 bit), για κάθε πακέτο δεδομένων, προκειμένου να το κρυπτογραφήσει, χρησιμοποιώντας το πρότυπο Advanced Encryption Standard (AES256).
2. Στη συνέχεια, το παραγόμενο κλειδί AES256 κρυπτογραφείται ασυμμετρικά με τα δημόσια κλειδιά της Αρχής (πιστοποιητικό X.509), σύμφωνα με τη διαδικασία RSA2048 (2048 -bit RSA keys).

Σχηματικά, η παραπάνω διαδικασία παρουσιάζεται στην εικόνα που ακολουθεί.

Εικόνα 3. Διαδικασία συμπίεσης και κρυπτογράφησης των δεδομένων

Στο δεύτερο βήμα πρέπει να παρέχεται η δυνατότητα ασυμμετρικής κρυπτογράφησης με περισσότερα του ενός δημόσια κλειδιά (πιστοποιητικά Χ.509), εφόσον αυτό ζητηθεί από την Αρχή.

Το ψηφιακό πιστοποιητικό το οποίο χρησιμοποιείται στην ανωτέρω διαδικασία δύναται να αντικαθίστανται με απόφαση της Αρχής.

25.3.1.5 Χρονοσήμανση δεδομένων

Είναι απαραίτητη η χρονοσήμανση των δεδομένων, ώστε να εξασφαλίζεται η ακεραιότητά τους και να συνδέονται τα δεδομένα με συγκεκριμένη χρονική στιγμή. Η χρονοσήμανση θα προστίθεται με τη μορφή ψηφιακής υπογραφής στο κάθε batch. Οι παραπάνω ψηφιακές υπογραφές θα πρέπει να μπορούν να υποστηρίξουν Timestamps από οποιονδήποτε Timestamp Server συμβατό με το ευρωπαϊκό πρότυπο eIDAS time-stamps ETSI EN 319 422 (RFC 3161). Τέλος, οι ψηφιακές υπογραφές χρονοσήμανσης θα πρέπει να είναι συμβατές με το πρότυπο XAdES-T.

25.3.2 Διασύνδεση του υποσυστήματος data sealing με το Safe

Η διασύνδεση του υποσυστήματος data sealing με το Safe γίνεται μέσω μιας ασφαλούς σύνδεσης εικονικού ιδιωτικού δικτύου (VPN), από άκρο σε άκρο.

25.3.3 Χωροθέτηση υποσυστήματος data sealing

Το υποσύστημα data capture μπορεί να φιλοξενείται εντός ΕΕ ή ΕΟΧ, αρκεί να πληρούνται οι προδιαγραφές που θέτει η Αρχή.

To data center που φιλοξενεί το υποσύστημα data sealing πρέπει να πληροί τις προδιαγραφές που περιγράφονται στο κεφάλαιο Ασφάλεια Υποδομών IT.

25.4 Αποθήκευση των δεδομένων

25.4.1 Τεχνικές προδιαγραφές διάταξης ασφαλούς αποθήκευσης δεδομένων

Ο πάροχος υπηρεσιών τυχερών παιγνίων μέσω διαδικτύου υποχρεούται να αποθηκεύει σε υλικό μηχανισμό (διάταξη ασφαλούς αποθήκευσης δεδομένων) τα δεδομένα που αφορούν στη διεξαγωγή τυχερών παιγνίων μέσω διαδικτύου, καθώς και τα δεδομένα που ανταλλάσσονται μεταξύ παίκτη, παρόχου υπηρεσιών διαδικτύου και χρηματοπιστωτικών ιδρυμάτων, σχετικά με τα παίγνια αυτά.

Οι ελάχιστες τεχνικές απαιτήσεις της διάταξης ασφαλούς αποθήκευσης δεδομένων παρουσιάζονται παρακάτω:

1. Η διάταξη ασφαλούς αποθήκευσης δεδομένων (Safe) πρέπει να λειτουργεί σαν αυτόνομη υποδομή, η οποία είναι φυσικά διαχωρισμένη από την κεντρική πλατφόρμα του παρόχου υπηρεσιών τυχερών παιγνίων.
2. Δεν επιτρέπεται η αποθήκευση δεδομένων στο Safe, εκτός των μοντελοποιημένων δεδομένων που ορίζει η Αρχή.
3. Ο Κάτοχος Αδείας πρέπει να εξασφαλίσει τη δημιουργία αντιγράφων ασφαλείας όλων των δεδομένων, σύμφωνα με τα οριζόμενα στην σχετική ενότητα. Η διάταξη ασφαλούς αποθήκευσης δεδομένων και ο εναλλακτικός χώρος αποθήκευσης των αντιγράφων ασφαλείας πρέπει να διαχωρίζονται γεωγραφικά, σύμφωνα με τα οριζόμενα στην σχετική ενότητα. Επιπλέον, η αποθήκευση δεδομένων σε δευτερεύοντα αποθηκευτικά μέσα (offline δεδομένα), όπως ορίζεται στην σχετική ενότητα, δε μπορεί να γίνεται στην ίδια γεωγραφική περιοχή που φιλοξενείται το αντίγραφο ασφαλείας του Safe (εναλλακτικός χώρος αποθήκευσης των αντιγράφων ασφαλείας).
4. Η πιστοποίηση που φέρει το Safe θα πρέπει να εντάσσεται στην πιστοποίηση του πληροφοριακού συστήματος του παρόχου τυχερών παιχνιδιών στο διαδίκτυο.
5. Ο Κάτοχος Άδειας πρέπει να εξασφαλίσει ότι η Αρχή θα έχει ασφαλή πρόσβαση τόσο στη διάταξη ασφαλούς αποθήκευσης των δεδομένων (Safe), όσο και στον εναλλακτικό χώρο αποθήκευσης, σύμφωνα με τα οριζόμενα στην σχετική ενότητα.
6. Στη διάταξη ασφαλούς αποθήκευσης δεδομένων, τα δεδομένα πρέπει να αποθηκεύονται ακολουθώντας την ονοματολογία και τη δομή αρχείων/φακέλων που καθορίζεται από την Αρχή, σύμφωνα με τα οριζόμενα στην σχετική ενότητα.
7. Τα δεδομένα που είναι αποθηκευμένα στο Safe πρέπει να ακολουθούν τα μοντέλα δεδομένων και τις καθορισμένες πρότυπες αναφορές που έχουν οριστεί από την Αρχή.
8. Τα δεδομένα που είναι αποθηκευμένα στο Safe πρέπει να είναι συμπιεσμένα και κρυπτογραφημένα, σύμφωνα με τα οριζόμενα στην σχετική ενότητα, ώστε μόνο η Αρχή να έχει πρόσβαση σε αυτά.
9. Οι Κάτοχοι Άδειας πρέπει να πιστοποιούν και να τεκμηριώνουν ότι το ενδιάμεσο σύστημα ελέγχου και η πύλη ελέγχου σε πραγματικό χρόνο (Gateway) συμμορφώνονται με τις απαιτήσεις που ορίζονται στο παρόν τεχνικό εγχειρίδιο.
10. Το Safe πρέπει να είναι διαθέσιμο 24/7, 365 ημέρες το χρόνο, με εγγυημένη διαθεσιμότητα τουλάχιστον 99,95%.
11. Οι Κάτοχοι Αδειών είναι υπεύθυνοι για τη λειτουργία του Safe, του ενδιάμεσου συστήματος ελέγχου και της πύλη ελέγχου σε πραγματικό χρόνο (Gateway).
12. Ο Κάτοχος της Άδειας πρέπει να εξασφαλίσει πρόσβαση στο Safe για την Αρχή, ώστε να είναι δυνατή η ακόλουθη σύνδεση: Η Αρχή πρέπει να έχει τη δυνατότητα πρόσβασης στο Safe μέσω μιας FTPS (FTP over SSL) σύνδεσης. Αναλυτικά οι προδιαγραφές της πρόσβασης της Αρχής στα δεδομένα περιγράφονται στη σχετική ενότητα.
13. Η πρόσβαση στα δεδομένα που περιλαμβάνονται τόσο στο Safe, όσο και στον εναλλακτικό χώρο αποθήκευσης γίνεται μόνο από προκαθορισμένες IP διευθύνσεις που κοινοποιούνται στον πάροχο από την Αρχή.
14. Ο Κάτοχος Άδειας οφείλει να τηρεί τις προδιαγραφές που αφορούν τις εργασίες συντήρησης και τα έκτακτα περιστατικά των υποδομών του ενδιάμεσου συστήματος και της πύλης Gateway.
15. Ο Κάτοχος Άδειας οφείλει σε περίπτωση που εντοπιστεί από την Αρχή πρόβλημα μη συμμόρφωσης των δεδομένων με τα μοντέλα που έχουν οριστεί, να ανταποκριθεί αμελλητί στη διόρθωσή και εκ νέου υποβολή τους. Η επικοινωνία μεταξύ Αρχής και Κατόχου Άδειας γίνεται σύμφωνα με τα οριζόμενα στη σχετική ενότητα.
16. Η Αρχή θα πρέπει να έχει φυσική πρόσβαση στους χώρους που φιλοξενούνται το Safe και η πύλη (Gateway), με δυνατότητες περιήγησης στο σύστημα αρχείων του Safe και αντιγραφής των δεδομένων του Safe σε αποσπώμενο μέσο αποθήκευσης.

25.4.2 Χωροθέτηση διάταξης ασφαλούς αποθήκευσης δεδομένων

Ο πάροχος οφείλει για φιλοξενεί τη διάταξη ασφαλούς αποθήκευσης δεδομένων εντός ελληνικής επικράτειας.

To data center που φιλοξενεί την υποδομή Safe πρέπει να πληροί τις προδιαγραφές που περιγράφονται στο κεφάλαιο Ασφάλεια Υποδομών IT.

25.4.3 Διαχωρισμός των δεδομένων

Τα δεδομένα που αποθηκεύονται στο Safe πρέπει να πληρούν τις τεχνικές προδιαγραφές που θέτει η Αρχή. Δεν επιτρέπεται η αποθήκευση δεδομένων στο Safe, εκτός των μοντελοποιημένων δεδομένων που ορίζονται από την Αρχή.

25.4.4 Μορφή αποθηκευμένων δεδομένων στη διάταξη ασφαλούς αποθήκευσης

Μετά τη διαδικασία κλειδώματος των δεδομένων που έχει περιγραφεί σε προηγούμενη ενότητα, τα συμπιεσμένα και κρυπτογραφημένα δεδομένα αποθηκεύονται στο Safe.

Κάθε πακέτο δεδομένων που αποθηκεύεται στο Safe περιλαμβάνει την εξής πληροφορία:

1. Το συμπιεσμένο και κρυπτογραφημένο πακέτο δεδομένων (περιλαμβάνει τις εγγραφές στη μορφή xml). Το αρχείο αυτό θα έχει πάντα την ονομασία data.bin.
2. Την απαραίτητη πληροφορία ελέγχου (control manifest) (περιγράφεται αναλυτικά στην σχετική ενότητα).

Η παραπάνω πληροφορία αποθηκεύεται με τη μορφή zip στο Safe. Το τελικό αρχείο zip αρχειοθετείται στο Safe στη δομή φακέλων της αντίστοιχης ημέρας. Το όνομα του τελικού αρχείου σχηματίζεται σύμφωνα με το ακόλουθο πρότυπο:

<licenseholder>_<licenseid>_<seqno>_<YYYYMMDD>_<hhmmss>.zip

Όπου:

• <licenseholder>: Όνομα του Κατόχου της Άδειας (πεζοί χαρακτήρες).
• <licenseid>: Αναγνωριστικό του τύπου άδειας του παρόχου.
• <seqno>: Αύξων αριθμός πακέτου δεδομένων, ανά licenseid (10 αριθμητικά ψηφία – leading zeros).
• <YYYYMMDD>:Ημερομηνία δημιουργίας.
• <hhmmss>: Ώρα δημιουργίας (24ωρη βάση).

25.4.5 Δομή και ονοματολογία πακέτων δεδομένων στη διάταξη ασφαλούς αποθήκευσης

Στη διάταξη ασφαλούς αποθήκευσης δεδομένων, τα τελικά πακέτα δεδομένων πρέπει να αποθηκεύονται ακολουθώντας την παρακάτω δενδρική δομή αρχείων/φακέλων και συγκεκριμένη ονοματολογία:

25.4.6 Διαθεσιμότητα παροχής υπηρεσιών

Η διαθεσιμότητα της διάταξης ασφαλούς αποθήκευσης δεδομένων, των λοιπών υποσυστημάτων του ενδιάμεσου συστήματος ελέγχου και της πύλης (Gateway), πρέπει να είναι τουλάχιστον 99,95%. Ο πάροχος οφείλει να τεκμηριώσει στην Αρχή τη διατήρηση της διαθεσιμότητα του συστήματος στο ποσοστό αυτό, παρέχοντας σχετικό πλάνο διαστασιολόγησης των προαναφερθέντων συστημάτων.

Σε περίπτωση βλάβης κάποιου υποσυστήματος (data capture ή/και data sealing) πρέπει τα δεδομένα που δεν έχουν παραληφθεί ακόμη από το υποσύστημα ασφαλούς αποθήκευσης, να παραληφθούν άμεσα μετά την εκ νέου έναρξη της ορθής λειτουργίας τους, έτσι ώστε τα δεδομένα να είναι ανελλιπή δομικά και χρονικά.

Επιπλέον, ο πάροχος καλείται να παρέχει εναλλακτικό πλάνο συνέχισης της παροχής των υπηρεσιών προς την Αρχή.

25.4.7 Διατήρηση των δεδομένων

Τα δεδομένα πρέπει να διατηρούνται στο Safe για χρονικό διάστημα δέκα (10) έτη.

Συγκεκριμένα, τα δεδομένα πρέπει να είναι διαθέσιμα online (άμεσα προσπελάσιμα) στην Αρχή, μέσω της διάταξης ασφαλούς αποθήκευσης, για τα πρώτα πέντε (5) έτη. Ακολούθως, τα δεδομένα μπορούν για ακόμη πέντε (5) έτη, να είναι αρχειοθετημένα σε δευτερεύοντα αποθηκευτικά μέσα (offline δεδομένα). Τα offline δεδομένα, πρέπει να διατηρούνται εντός του ενδιάμεσου συστήματος ελέγχου και εντός ελληνικής επικράτειας. Σε κάθε περίπτωση, η φιλοξενία των offline δεδομένων δε μπορεί να γίνεται στην ίδια γεωγραφική περιοχή που φιλοξενείται το αντίγραφο ασφαλείας του Safe (εναλλακτικός χώρος αποθήκευσης των αντιγράφων ασφαλείας).

Το αργότερο σε δύο (2) ημερολογιακές ημέρες πρέπει τα offline δεδομένα να μπορούν να είναι άμεσα προσπελάσιμα από την Αρχή, μέσω της διάταξης ασφαλούς αποθήκευσης.

Μετά το πέρας των δέκα 10 ετών πρέπει τα δεδομένα να διαγράφονται, χωρίς δυνατότητα ανάκλησης.

25.4.8 Αντίγραφα ασφαλείας

Τα δεδομένα στη διάταξη ασφαλούς αποθήκευσης δεδομένων πρέπει να αντιγράφονται με ασφάλεια σε έναν εναλλακτικό αποθηκευτικό χώρο, ώστε να μην υπάρχει απώλεια δεδομένων, σε περίπτωση ενός σοβαρού περιστατικού καταστροφής του κύριου αποθηκευτικού χώρου.

Ο εναλλακτικός χώρος αποθήκευσης θα πρέπει να βρίσκεται σε απόσταση τουλάχιστον 30 χιλιομέτρων από την κύρια διάταξη ασφαλούς αποθήκευσης και να συγχρονίζεται με αυτή κάθε 30 λεπτά, με μια ασφαλή σύνδεση αφιερωμένη αποκλειστικά για το σκοπό αυτό. Στον εναλλακτικό χώρο αποθήκευσης θα πρέπει να διαθέτει διαβαθμισμένη απομακρυσμένη πρόσβαση και η Αρχή (όπως περιγράφεται και στη σχετική ενότητα).

To data center που φιλοξενεί την υποδομή του εναλλακτικού χώρου αποθήκευσης πρέπει να βρίσκεται εντός ΕΕ ή ΕΟΧ και να πληροί τις προδιαγραφές που περιγράφονται στο κεφάλαιο Ασφάλεια Υποδομών IT.

Σε περίπτωση ενός σοβαρού περιστατικού καταστροφής του κύριου αποθηκευτικού χώρου, το χρονικό διάστημα επαναφοράς του σε πλήρη λειτουργία, με όλα τα δεδομένα, όπως ήταν στην προτέρα κατάστασή του, δε μπορεί να ξεπερνά τις πέντε (5) ημερολογιακές ημέρες.

Σε μια τέτοια περίπτωση ο πάροχος οφείλει να ενημερώσει αμελλητί την Αρχή για το συμβάν, να τεκμηριώσει λεπτομερώς τα αίτια του συμβάντος και να καταθέσει πλάνο για την επαναφορά της υποδομής στην προτέρα κατάσταση.

Για την έναρξη της επαναφοράς των δεδομένων από τον εναλλακτικό χώρο αποθήκευσης στον κύριο, απαιτείται η έγκριση της Αρχής.

25.4.9 Εγκατάσταση πειραματικού λογαριασμού παιχνιδιού για την Αρχή

Ο πάροχος πρέπει να δημιουργήσει για την Αρχή έναν πειραματικό λογαριασμό παιχνιδιού, ο οποίος καθιστά δυνατή τη συμμετοχή στο παιχνίδι κάτω από πραγματικές συνθήκες, εξαιρουμένων των δυνατοτήτων της κατάθεσης χρημάτων και πληρωμής.

Όλες οι δραστηριότητες του πειραματικού λογαριασμού παιχνιδιού πρέπει, όπως τα δεδομένα των πραγματικών παικτών, να καταγράφονται στη διάταξη ασφαλούς αποθήκευσης δεδομένων.

25.4.10 Διόρθωση δεδομένων / Ακύρωση εγγραφής

Όταν απαιτείται η διόρθωση δεδομένων που έχουν ήδη αποσταλεί προς μόνιμη αποθήκευση στη διάταξη ασφαλούς αποθήκευσης (Safe), τότε ο πάροχος αποστέλλει τη νέα εγγραφή διατηρώντας αναφορά στην εγγραφή προς αντικατάσταση. Ειδικότερα:

• Δημιουργείται μια νέα πλήρης εγγραφή, με το σύνολο των δεδομένων που υπάρχουν στην προς αντικατάσταση εγγραφή και με ειδική αναφορά στην αρχική καταγεγραμμένη εγγραφή (previous record id).
• Στην περίπτωση που πρέπει να γίνει ακύρωση μιας εγγραφής, δε δημιουργείται μια πλήρης κενή εγγραφή όπως παραπάνω, αλλά γίνεται χρήση ειδικού μοντέλου δεδομένων για το σκοπό αυτό. Για κάθε ακύρωση εγγραφής απαιτείται επαρκή αιτιολόγηση της ενέργειας και χρονοσήμανσή της.

25.4.11 Κατ’ απαίτηση αποστολή δεδομένων

Η Αρχή μπορεί να ζητά από τον Κάτοχο της Άδειας συμπληρωματικά δεδομένα, εφόσον κρίνεται σκόπιμο. Σε περίπτωση που το μοντέλο των δεδομένων που ζητούνται από την Aρχή, δε συμπεριλαμβάνεται στη λίστα με τα διαθέσιμα μοντέλα δεδομένων, η Aρχή οφείλει να αποστέλλει στον Κάτοχο της Άδειας και το σχετικό μοντέλο δεδομένων.

Η διαδικασία αποθήκευσης του νέου πακέτου δεδομένων στη διάταξη ασφαλούς αποθήκευσης θα ακολουθεί την ίδια διαδικασία που ισχύει για όλα τα πακέτα δεδομένων, όπως έχει περιγραφεί σε προηγούμενη ενότητα.

Τα αρχεία που αποθηκεύονται στη διάταξη ασφαλούς αποθήκευσης θα πρέπει να φέρουν το χαρακτηριστικό αναγνωριστικό «_od_» στην ονομασία τους, στη συνέχεια του αναγνωριστικού <licenceid>, ώστε να διασφαλιστεί η αναγνώρισή τους ως «κατ’ απαίτηση δεδομένα».

Παράδειγμα:

<LICENSEHOLDER>_<licenceid>_od_000000000Ν_<20180101>_<13:00:00>.zip

25.5 Πύλη ελέγχου σε πραγματικό χρόνο (Gateway)

Μέσω της πύλης ελέγχου σε πραγματικό χρόνο, όλη η διαδικτυακή κίνηση των παικτών κατευθύνεται στην κεντρική πλατφόρμα του παρόχου.

Τα τυχερά παίγνια διεξάγονται μέσω ιστοτόπων που έχουν υποχρεωτικά ονομασία χώρου (Domain name) με κατάληξη .gr. Έτσι, η πρόσβαση στις υπηρεσίες του παρόχου, μέσω της πύλης Gateway, μπορεί να γίνει μόνο από ιστοτόπους με κατάληξη «.gr» για την Ελλάδα.

Ο πάροχος οφείλει για φιλοξενεί την πύλη Gateway εντός ΕΕ ή ΕΟΧ. To data center που φιλοξενεί την πύλη πρέπει να πληροί τις προδιαγραφές που περιγράφονται στο κεφάλαιο Ασφάλεια Υποδομών IT.

Τέλος, ο Κάτοχος της Άδειας εξασφαλίζει ότι, τα δεδομένα πύλης είναι σε τέτοια μορφή, ώστε να μπορούν να χρησιμοποιηθούν από μια διαδικασία ελέγχου της Αρχής. Συγκεκριμένα, θα πρέπει να παρέχεται στην Αρχή η δυνατότητα της παρακολούθησης και της εγγραφής για πεπερασμένο χρονικό διάστημα, όλων των συναλλαγών (κίνηση διαδικτύου) που λαμβάνουν χώρα, σε πραγματικό χρόνο, από τους παίκτες και διοχετεύονται, μέσω της πύλης, στην κεντρική πλατφόρμα του παρόχου.

25.6 Διαχείριση της πρόσβασης στα δεδομένα και λοιπές υποχρεώσεις Κατόχου Άδειας

25.6.1 Μέθοδοι και διαχείριση της πρόσβασης στα δεδομένα

Πρόσβαση στα δεδομένα που αποθηκεύονται στον κύριο αποθηκευτικό χώρο έχει μόνο η Αρχή.

Η πρόσβαση στα δεδομένα από την Αρχή γίνεται μέσω μιας σύνδεσης FTPS (FTP-SSL, implicit) στην πόρτα 990. Για την πρόσβαση απαιτείται η χρήση ψηφιακού πιστοποιητικού X.509 που εκδίδεται από την Αρχή.

Η πρόσβαση στον εναλλακτικό χώρο αποθήκευσης πραγματοποιείται με τον ίδιο ακριβώς τρόπο.

Η πρόσβαση στα δεδομένα που περιλαμβάνονται τόσο στο Safe, όσο και στον εναλλακτικό χώρο αποθήκευσης γίνεται μόνο από προκαθορισμένες IP διευθύνσεις που ορίζονται από την Αρχή και κοινοποιούνται στον Κάτοχο της Άδειας.

Η μεταφορά δεδομένων μεταξύ του Safe και της Αρχής πρέπει να πραγματοποιείται μέσω του Διαδικτύου, με ελάχιστη ταχύτητα 8 Mbit / δευτερόλεπτο. Ο Κάτοχος της Άδειας πρέπει να διασφαλίζει ότι η σύνδεση είναι κατάλληλη για την ομαλή μεταφορά των δεδομένων.

Ο μέσος χρόνος που απαιτείται προκειμένου η Αρχή να αποκτήσει πρόσβαση στα δεδομένα (login time) δε μπορεί να υπερβαίνει τα 15 δευτερόλεπτα.

25.6.2 Διαθεσιμότητα της πρόσβασης στα δεδομένα

Όπως αναφέρθηκε και παραπάνω, η διαθεσιμότητα τόσο της διάταξης ασφαλούς αποθήκευσης, όσο των λοιπών υποσυστημάτων του ενδιάμεσου συστήματος ελέγχου, αλλά και της πύλης Gateway, πρέπει να είναι τουλάχιστον 99,95%. Στην περίπτωση της πρόσβασης στα δεδομένα, η Αρχή θα πρέπει να διαθέτει διαβαθμισμένη πρόσβαση και στον εναλλακτικό χώρο αποθήκευσης, σε περίπτωση μη διαθεσιμότητας του κύριου αποθηκευτικού χώρου.

25.6.3 Συμπληρωματικοί τρόποι πρόσβασης στα δεδομένα

Στην Αρχή, εκτός της πρόσβασης στα δεδομένα, μέσω του Safe, παρέχονται και οι παρακάτω δυνατότητες απομακρυσμένης πρόσβασης:

• Μέσω της πύλης Gateway: Στην Αρχή παρέχεται η δυνατότητα της παρακολούθησης και της εγγραφής, για πεπερασμένο χρονικό διάστημα, όλων των συναλλαγών (κίνηση διαδικτύου) που λαμβάνουν χώρα, σε πραγματικό χρόνο, από τους παίκτες και κατευθύνονται μέσω της πύλης στην κεντρική πλατφόρμα του παρόχου.
• Μέσω της Κεντρικής πλατφόρμας του Παρόχου: Κατόπιν ειδοποίησης, ο Κάτοχος της Άδειας οφείλει να παρέχει πρόσβαση στην Aρχή, στο σύστημα βάσεων δεδομένων της κεντρικής πλατφόρμας του παρόχου, μέσω μιας read-only σύνδεσης απομακρυσμένης επιφάνειας εργασίας (μέσω εκπροσώπου του παρόχου). Στο πλαίσιο της εν λόγω συνεδρίας, ενδέχεται να ζητηθεί από τον εκπρόσωπο του παρόχου η εμφάνιση, η αποθήκευση και η αποστολή στην Αρχή συγκεκριμένων συνόλων δεδομένων που ορίζει η Αρχή.

25.6.4 Φυσική πρόσβαση στο ενδιάμεσο σύστημα ελέγχου και στην πύλη Gateway

Κατόπιν αιτήματος της Αρχής θα πρέπει να παρέχεται η δυνατότητα φυσικής πρόσβασης στους χώρους που φιλοξενούνται τα υποσυστήματα του ενδιάμεσου συστήματος ελέγχου και η πύλη (Gateway). Στο πλαίσιο αυτό, με στόχο τη διευκόλυνση του ελεγκτικού και εποπτικού έργου της Αρχής, θα πρέπει τα δεδομένα τόσο στο Safe, όσο και στην πύλη (Gateway), να είναι επιτόπου προσπελάσιμα από εξουσιοδοτημένα στελέχη της Αρχής.

Ταυτόχρονα, η Αρχή θα πρέπει να έχει τη δυνατότητα αντιγραφής των δεδομένων του Safe σε αποσπώμενο μέσο αποθήκευσης.

25.6.5 Συντήρηση της διάταξης ασφαλούς αποθήκευσης (Safe) από τον Κάτοχο Άδειας

Η συντήρηση και ο τεχνικός έλεγχος των υποδομών του ενδιάμεσου συστήματος ελέγχου και της πύλης Gateway είναι αποκλειστική αρμοδιότητα του Κατόχου της Άδειας. Ο Κάτοχος της Άδειας οφείλει να τηρεί τις διαδικασίες που περιγράφονται αναλυτικά στην ΔΙΑΧΕΙΡΙΣΗ ΑΛΛΑΓΩΝ ΣΤΑ ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΕΞΑΓΩΓΗΣ ΤΥΧΕΡΩΝ ΠΑΙΓΝΙΩΝ ΤΩΝ ΚΑΤΟΧΩΝ ΑΔΕΙΑΣ. Επιπρόσθετα, για τη διάταξη ασφαλούς αποθήκευσης (Safe), πρέπει να τηρούνται και οι προδιαγραφές που ορίζονται στον πίνακα που ακολουθεί.

Πίνακας 1. Προδιαγραφές για τη συντήρηση του Safe από τον Κάτοχο Άδειας

25.6.6 Έκτακτα περιστατικά της διάταξης ασφαλούς αποθήκευσης (Safe)

Σε περίπτωση που συμβεί κάποιο έκτακτο περιστατικό, το οποίο επηρεάζει την απρόσκοπτη λειτουργία του Safe, πρέπει αυτό να κοινοποιείται στην Αρχή και να επιλύεται, σύμφωνα με τα οριζόμενα στον πίνακα που ακολουθεί.Όλα τα έκτακτα περιστατικά πρέπει να επιλύονται σε ποσοστό τουλάχιστον 95%, το οποίο μετριέται σε τριμηνιαία βάση.Η υποβολή των εκτάκτων περιστατικών πραγματοποιείται σύμφωνα τις διαδικασίες που περιγράφονται αναλυτικά στην ΔΙΑΧΕΙΡΙΣΗ ΑΛΛΑΓΩΝ ΣΤΑ ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΕΞΑΓΩΓΗΣ ΤΥΧΕΡΩΝ ΠΑΙΓΝΙΩΝ ΤΩΝ ΚΑΤΟΧΩΝ ΑΔΕΙΑΣ.

Πίνακας 2. Προδιαγραφές για αντιμετώπιση έκτακτων περιστατικών

25.6.7 Υπεύθυνοι επικοινωνίας Κατόχου Άδειας για τεχνικά θέματα

Εκτός από τις απαιτήσεις σχετικά με τους διαφορετικούς ρόλους και τα άτομα, που η νομοθεσία ορίζει ως προϋπόθεση για την έκδοση άδειας, ο Κάτοχος Άδειας πρέπει να καθορίσει τουλάχιστον τους ακόλουθους τεχνικούς ρόλους:

• Υπεύθυνος για τη λειτουργία και την ασφάλεια του ενδιάμεσου συστήματος και λοιπών υποσυστημάτων.
• Υπεύθυνος για τις τεχνικές εργασίες και τη συντήρηση της υποδομής.

25.7 Μοντέλα δεδομένων

25.7.1 Μοντέλα δεδομένων

Τα μοντέλα δεδομένων είναι διαθέσιμα στην ιστοσελίδα της Ε.Ε.Ε.Π. (https://www.gamingcommission.gov.gr).

25.7.2 Μοντέλο δεδομένων για το αρχείο ελέγχου xml

25.7.2.1 Ονοματολογία xml αρχείου

Το αρχείο ελέγχου xml πρέπει έχει την ονομασία «manifest.xml».

25.7.2.2 Σχηματική περιγραφή μοντέλου δεδομένων xsd

Εικόνα 4. Μοντέλο δεδομένων για το αρχείο ελέγχου xml

25.7.2.3 Αναλυτική περιγραφή μοντέλου δεδομένων xsd

Το αρχείο ελέγχου είναι ένα συμπληρωματικό αρχείο xml, το οποίο συνοδεύει κάθε πακέτο δεδομένων που αποθηκεύεται στο Safe. Φέρει όλη την απαραίτητη πληροφορία ελέγχου (μεταδεδομένα) του εκάστοτε αρχείου δεδομένων xml που περιέχεται σε κάθε πακέτο δεδομένων. Οι βασικότερες πληροφορίες που περιέχονται στο αρχείο ελέγχου αφορούν τα αναγνωριστικά διασύνδεσης των διαδοχικών πακέτων δεδομένων (chaining hash values), τις παραμέτρους που χρησιμοποιούνται για τη συμπίεση και την κρυπτογράφηση των πακέτων δεδομένων και την ψηφιακή υπογραφή κάθε πακέτου δεδομένων που αποθηκεύεται στο Safe.

Ειδικότερα, η πληροφορία που περιέχεται στο αρχείο ελέγχου είναι η εξής:

• Αναγνωριστικό, μονοσήμαντο όνομα του Κατόχου της Άδειας (hgc:licenseholderId).
• Ημερομηνία και ώρα δημιουργίας του αρχείου ελέγχου (hgc:generationDate).
• Αύξων αριθμός του αρχείου ελέγχου (hgc:manifestSequenceNumber).
• Μεταδεδομένα του αρχείου δεδομένων xml του πακέτου δεδομένων (hgc:metadata):
  • Αριθμός εγγραφών που περιέχονται στο αρχείο xml (hgc:numberOfRecords).
  • Ημερομηνία και ώρα της πρώτης εγγραφής στο αρχείο xml (hgc:datetimeFirstRecord).
  • Ημερομηνία και ώρα της τελευταίας εγγραφής στο αρχείο xml (hgc:datetimeLastRecord).
  • Μέγεθος του μη συμπιεσμένου αρχείου δεδομένων xml σε bytes (hgc:sizeUncompressed).
  • Μέγεθος του συμπιεσμένου αρχείου δεδομένων xml σε bytes (hgc:sizeCompressed).
• To δυναμικά παραγόμενο συμμετρικό κλειδί (AES256), με το οποίο είναι ασυμμετρικά κρυπτογραφημένο το αρχείο δεδομένων, κάνοντας χρήση του δημόσιου κλειδιού της Αρχής (πιστοποιητικό X.509), σύμφωνα με το πρότυπο W3C XML Encryption (https://www.w3.org/TR/xmlenc-core/) (xenc:EncryptedKey).
• Αναφορά στα κρυπτογραφημένα δεδομένα σύμφωνα με το πρότυπο W3C XML Encryption (xenc:EncryptedData).
• Οι πληροφορίες σύνδεσης των διαδοχικών πακέτων δεδομένων (chaining) (dsig:Manifest).
• Η ψηφιακή υπογραφή του πακέτου δεδομένων, συμπεριλαμβανομένης και της χρονοσήμανσης του, σύμφωνα με το πρότυπο XAdES (dsig:Signature).

Παρακάτω παρουσιάζονται λεπτομέρειες για τη μεθοδολογία σύνταξης του αρχείου ελέγχου xml.

/hgc:licenseholderId

Αναγνωριστικό, μονοσήμαντο όνομα του Κατόχου της Άδειας.

/hgc:generationDate

Ημερομηνία και ώρα δημιουργίας του αρχείου ελέγχου.

/hgc:manifestSequenceNumber

Αύξων αριθμός του αρχείου ελέγχου (Ακέραιος αριθμός Ν >=1). Ταυτίζεται με τον αύξοντα αριθμό πακέτου δεδομένων.

/hgc:metadata

Μεταδεδομένα του αρχείου δεδομένων xml του πακέτου δεδομένων (συγκεντρωτικά δεδομένα).

/hgc:metadata/hgc:numberOfRecords

Αριθμός εγγραφών που περιέχονται στο αρχείο xml.

/hgc:metadata/hgc:dateFirstRecord

Ημερομηνία και ώρα της πρώτης εγγραφής στο αρχείο xml.

/hgc:metadata/hgc:dateLastRecord

Ημερομηνία και ώρα της τελευταίας εγγραφής στο αρχείο xml.

/hgc:metadata/hgc:sizeUncompressed

Μέγεθος του μη συμπιεσμένου αρχείου δεδομένων xml σε bytes

/hgc:metadata/hgc:sizeCompressed

Μέγεθος του συμπιεσμένου αρχείου δεδομένων xml σε bytes.

/xenc:EncryptedKey

Το στοιχείο <xenc:EncryptedKey> περιέχει το δυναμικά παραγόμενο συμμετρικό κλειδί (AES256), με το οποίο είναι ασυμμετρικά κρυπτογραφημένο το αρχείο δεδομένων, κάνοντας χρήση του δημόσιου κλειδιού της Αρχής (πιστοποιητικό X.509), σύμφωνα με το πρότυπο W3C XML Encryption. Το στοιχείο επίσης περιέχει ένα αναγνωριστικό όνομα για την αναγνώριση του συμμετρικού κλειδιού <xenc: CarriedKeyName>.

Σύμφωνα με το πρότυπο W3C XML Encryption, η δομή του συγκεκριμένου στοιχείου θα πρέπει να είναι ως εξής:

Στην περίπτωση που υπάρχουν περισσότερα πιστοποιητικά κρυπτογράφησης X.509 της/των ελεγκτικής(-ών) αρχής(-ών), τότε πρέπει να δημιουργηθούν περισσότερα στοιχεία <xenc:EncryptedKey>, τα οποία θα περιέχουν το ίδιο συμμετρικό κλειδί και όνομα, αλλά θα δείχνουν στο εκάστοτε πιστοποιητικό κρυπτογράφησης X.509 της ελεγκτικής αρχής (ds:X509SubjectName). Σαν αναγνωριστικό Id του στοιχείου <xenc:EncryptedKey>, θα δίνεται ένα αναγνωριστικό όνομα για την εποπτεύουσα αρχή για την οποία δημιουργείται το στοιχείο αυτό. Το αναγνωριστικό όνομα θα κοινοποιηθεί στον Κάτοχο της Άδειας από την Αρχή.

Σαν όνομα του για την αναγνώριση του συμμετρικού κλειδιού <xenc: CarriedKeyName> χρησιμοποιούμε τον αύξοντα αριθμό του αρχείου ελέγχου (π.χ. 20), με την προσθήκη του προθέματος K (Key).

/xenc:EncryptedData

Αυτό το στοιχείο αντιπροσωπεύει την αναφορά στα κρυπτογραφημένα δεδομένα, σύμφωνα με το πρότυπο κρυπτογράφησης XML Encryption. Περιέχει τον αλγόριθμο κρυπτογράφησης (AES256), καθώς και την εσωτερική αναφορά στο συμμετρικό κλειδί, μέσω του ονόματός του <xenc: CarriedKeyName>.

Η αναφορά στα κρυπτογραφημένα δεδομένα γίνεται μέσω ενός URI, το οποίο σχηματίζεται ως ακολούθως:

• Τη διαδρομή URL του αρχείου zip. Η διαδρομή αντιστοιχεί στη δενδρική δομή φακέλων του Safe. Παράδειγμα:

<licenseholder>_<licenseid>_<seqno>_<YYYYMMDD>_<hhmmss>.zip

• Τη διαδρομή του συμπιεσμένου και κρυπτογραφημένου αρχείου δεδομένων data.bin μέσα στο αρχείο zip. Παράδειγμα:

/data.bin

Στο τελικό στοιχείο <xenc:EncryptedData> προστίθεται ένα αναγνωριστικό Id, βάσει του οποίου θα γίνει η σύνδεση των διαδοχικών πακέτων (chaining), όπως παρουσιάζεται παρακάτω στην περιγραφή του στοιχείου < dsig:manifest >.

Συνεπώς, το στοιχείο <xenc:EncryptedData> θα έχει την παρακάτω μορφή:

Στο παραπάνω παράδειγμα, το αναγνωριστικό του στοιχείου <xenc:EncryptedData> (Id=»D20″), προκύπτει από τον αύξοντα αριθμό του πακέτου (20), με την προσθήκη του προθέματος D (Data), επειδή γίνεται αναφορά στο πακέτο δεδομένων.

Στην περίπτωση που έπρεπε να γίνει κάποια αναφορά στο αρχείο ελέγχου (manifest), χρησιμοποιούμε τον αύξοντα αριθμό του αρχείου ελέγχου (20), με την προσθήκη του προθέματος C (Control).

/dsig:manifest

Για τη σύνδεση των διαδοχικών πακέτων (batches) μεταξύ τους χρησιμοποιείται το στοιχείο <dsig:Manifest>. Το στοιχείο αυτό προέρχεται από το πρότυπο XadES (XMLDSIG). Περιέχει δύο αναφορές στα δεδομένα (τρέχοντος και προηγούμενου πακέτου) , συμπεριλαμβανομένων των αντίστοιχων hash τιμών τους.

Η δομή του στοιχείου αυτού συνοψίζεται ως εξής:

• Περιέχει αναφορά στο αντίστοιχο <dsig:Manifest> στοιχείο του αμέσως προηγούμενου πακέτου zip που δημιουργήθηκε, συμπεριλαμβανομένης και της hash τιμής του αρχείου δεδομένων xml που υπολογίστηκε βάσει του προηγούμενου κανονικοποιημένου αρχείου δεδομένων xml (προδιαγραφή Exclusive XML Canonicalization [XML-C14N]).

Η αναφορά στο προηγούμενο πακέτο δεδομένων γίνεται μέσω ενός URI, το οποίο σχηματίζεται ως ακολούθως:

• Τη διαδρομή URL του προηγούμενου αρχείου zip. Η διαδρομή αντιστοιχεί στη δενδρική δομή φακέλων του Safe, όπως ορίζεται στις ενότητες 5.4 και 5.11. Παράδειγμα:

<licenseholder>_<licenseid>_<seqno>_<YYYYMMDD>_<hhmmss>.zip

• Τη διαδρομή του αρχείου ελέγχου manifest xml μέσα στο προηγούμενο αρχείο zip. Παράδειγμα:

/manifest.xml

• Την αναφορά στο αναγνωριστικό Id του στοιχείου <dsig:Manifest> του προηγούμενου πακέτου zip (<dsig:Manifest Id=”PreviousID”>). Παράδειγμα:

#<Id>

• Περιέχει αναφορά στο στοιχείο <xenc:EncryptedData> του τρέχοντος αρχείου ελέγχου, συμπεριλαμβανομένης και της hash τιμής του αρχείου δεδομένων xml που υπολογίστηκε βάσει του τρέχοντος κανονικοποιημένου αρχείου δεδομένων xml (προδιαγραφή Exclusive XML Canonicalization [XML-C14N]). Η τιμή hash υπολογίζεται στο μη κρυπτογραφημένο και μη συμπιεσμένο αρχείο δεδομένων xml.

Στη συνέχεια πρέπει να αναφέρονται οι κανόνες μετασχηματισμού (αποκρυπτογράφηση, αποσυμπίεση) που πρέπει να εφαρμοστούν προκειμένου να γίνει επαλήθευση της τιμής hash ενός πακέτου δεδομένων.

Συνεπώς, το στοιχείο <dsig:Manifest> θα έχει την παρακάτω μορφή:

/dsig:Signature

Πρόκειται για το στοιχείο που περιλαμβάνει την ψηφιακή υπογραφή του πακέτου δεδομένων. Η ψηφιακή υπογραφή προστίθεται ως enveloped signature σύμφωνα με το πρότυπο XAdES, συμπεριλαμβανομένης και της χρονοσήμανσης (πρότυπο XΑdES-T).