computer security

1 algorithms

1.1 RSA

Is the best bet if you can't use Ed25519.

1.2 DSA

man ssh-keygen

says that a DSA key has to be exactly 1024 bits long to be compliant with NIST's FIPS 186-2. So although in theory longer DSA keys are possible (FIPS 186-3 also explicitly allows them) you are still restricted to 1024 bits.

DSA and ECDSA have a nasty property: they require a parameter usually called k to be completely random, secret, and unique. In practice that means that if you connect to your server from a machine with a poor random number generator and e.g. the the same k happens to be used twice, an observer of the traffic can figure out your private key.

1.3 Ed25519

probably the strongest mathematically (and also the fastest), but not yet widely supported. As a bonus, it has stronger encryption (password-protection) of the private key by default than other key types.

1.4 aliases

ADH all ciphers using Anonymous Diffie-Hellman key exchange
AECDH all ciphers using Anonymous Elliptic Curve Diffie-Hellman key exchange
aNULL all ciphers using no authentication
DH all ciphers using Diffie-Hellman key exchange
DSS all ciphers using DSS authentication
ECDH Elliptic Curve Diffie-Hellman key exchange
ECDSA all ciphers using ECDSA authentication
EDH all ciphers using Ephemeral Diffie-Hellman key exchange
EXP all export ciphers
EXPORT40 all 40-bit export ciphers only
EXPORT56 all 56-bit export ciphers only
HIGH all ciphers using Triple-DES
LOW all low strength ciphers (no export, single DES)
MEDIUM all ciphers with 128 bit encryption
RSA all ciphers using RSA key exchange
SRP all ciphers using Secure Remote Password (SRP) key exchange
SSLv3 all SSL version 3.0 ciphers
TLSv1 all TLS version 1.0 ciphers

1.5 authentication algorithms

aNULL No authentication
aRSA RSA authentication
aDSS DSS authentication
aDH Diffie-Hellman authentication

1.6 cipher encoding algorithms

eNULL No encryption
NULL alias for eNULL
AES AES encryption
DES DES encryption
3DES Triple-DES encryption
RC4 RC4 encryption
RC2 RC2 encryption
IDEA IDEA encryption

1.7 Dual EC - pseudorandom number generator

Engineered and promoted by NSA. Has built in backdoor. Was part of an organized approach to weakening cryptographic standards.

1.8 ECC - Elliptic Curve Cryptography

Approach to public-key cryptography based on the algebraic structure of elliptic curves over finite fields. ECC requires smaller keys compared to non-ECC cryptography (based on plain Galois fields) to provide equivalent security

1.8.1 ECDSA - Elliptic Curve Digital Signing Algorithm

Offers a variant of the Digital Signature Algorithm (DSA) which uses elliptic curve cryptography.

1.9 encryption algorithm (in general)

There are several encryption algorithms available:

  • using symmetric or asymmetric methods,
  • with keys of various lengths.

Usually, algorithms cannot be patented, if Henri Poincare had patented his algorithms, then he would have been able to sue Albert Einstein…

So algorithms cannot be patented except mainly in USA.

OpenSSL is developed in a country where algorithms cannot be patented and where encryption technology is not reserved to state agencies like military and secret services.

During the negotiation between browser and web server, the applications will indicate to each other a list of algorithms that can be understood ranked by order of preference. The common preferred algorithm is then chosen.

OpenSSL can be compiled with or without certain algorithms, so that it can be used in many countries where restrictions apply.

1.10 key exchange algorithms

kRSA RSA key exchange
kDHr Diffie-Hellman key exchange with RSA key
kDHd Diffie-Hellman key exchange with DSA key
kEDH Ephemeral (temp.key) Diffie-Hellman key exchange (no cert)
kSRP Secure Remote Password (SRP) key exchange

1.11 MAC digest algorithms

MD5 MD5 hash function
SHA1 SHA1 hash function
SHA alias for SHA1
SHA256 SHA256 hash function
SHA384 SHA384 hash function

2 backdoors

2.1 hardware backdoors

2.1.1 Baseband processors on every mobile phone

Every smartphone or other device with mobile communications capability (e.g. 3G or LTE) actually runs not one, but two operating systems.

Aside from the operating system that we as end-users see (Android, iOS, PalmOS), it also runs a small operating system that manages everything related to radio. This operating system is stored in firmware, and runs on the baseband processor.

Baseband processor inherently trusts whatever data it receives from a base station (e.g. in a cell tower). Nothing is checked, everything is automatically trusted. Lastly, the baseband processor is usually the master processor, whereas the application processor (which runs the mobile operating system) is the slave.

Put a compromised base station in a crowded area - or even a financial district or some other sensitive area - and you can remotely turn on microphones, cameras, place rootkits, place calls/send SMS messages to expensive numbers, and so on.

Basically that black box system has full access to the RAM of the device, while also being the main communication component. This is really nasty.

  • SIM card contains kind of an OS too.
  • Bluetooth, Wifi, GPS and touch chips have an internal processor too, running their internal software, which can be quite complex. They tend to use small ARM cores (M3, M0), and generally use an RTOS.
  • SD card runs its own firmware, too.

2.1.2 AMT (Intel)

  1. capabilities

    The AMT processor has total control over the machine. Here are some of the things it has the ability to do, remotely over a network:

    • power control
    • BIOS configuration and upgrade
    • disk wipe
    • system re-installation
    • console access (VNC)

    The AMT runs even when the computer is powered off, as long as the machine is plugged into a power outlet.

  2. deactivate AMT
    1. Hold down keys CTRL + P while computer is booting.
    2. AMT enabled systems will show AMT login dialog.
    3. Log in to AMT console. Default password is "admin".
    4. Change default password. AMT requires strong password.
    5. Disable AMT from within menu.

2.1.3 BMC (Intel)

The BMC is an embedded computer found on most server motherboards made in the last 10 or 15 years.

Often running Linux, the BMC's CPU, memory, storage, and network run independently. It runs Intel's IPMI out-of-band systems management protocol alongside network services (web, telnet, VNC, SMTP, etc.) to help manage, debug, monitor, reboot, and roll out servers, virtual systems, and supercomputers.

Vendors frequently add features and rebrand OEM'd BMCs: Dell has iDRAC, Hewlett Packard iLO, IBM calls theirs IMM2, etc.

Basically, it's a perfect spying platform. You can't control it. You can't patch it. It can completely control your computer's hardware and software. And its purpose is remote monitoring.

2.1.4 iDRAC (DELL)

2.1.5 iLO (Hewlett Packard)

2.1.6 IMM2 (IBM)

2.1.7 Intel Management Engine (Intel)

  • http://libreboot.org/faq/#intelme
  • ME is present on all Intel desktop, mobile (laptop), and server systems since mid 2006.
  • has network access
  • operating system kernel is based on a proprietary real-time operating system (RTOS) kernel called "ThreadX"
  • consists of a Java virtual machine and set of preinstalled Java classes for cryptography, secure storage, etc. The DAL module can load and execute additional ME modules from the PC's HDD or SSD
  • Is part of the Intel "vPro" brand, is a Web server and application code that enables remote users to power on, power off, view information about, and otherwise manage the PC. It can be used remotely even while the PC is powered off (via Wake-on-Lan). Traffic is encrypted using SSL/TLS libraries, but recall that all of the major SSL/TLS implementations have had highly publicized vulnerabilities. The AMT application itself has known vulnerabilities, which have been exploited to develop rootkits and keyloggers and covertly gain encrypted access to the management features of a PC. Remember that the ME has full access to the PC's RAM. This means that an attacker exploiting any of these vulnerabilities may gain access to everything on the PC as it runs: all open files, all running applications, all keys pressed, and more.

2.1.8 PSP - Platform Security Processor (AMD)

  • https://libreboot.org/faq/#amd
  • Basically AMD's own version of the Intel Management Engine
  • Is an ARM core with TrustZone technology, built onto the main CPU die. As such, it has the ability to hide its own program code,scratch RAM, and any data it may have taken and stored from the lesser-privileged x86 system RAM (kernel encryption keys, login data, browsing history, keystrokes, …)

2.2 RSA, NIST and NSA collaborated in standardizing backdoored Dual EC

December 2013: Reuters reported that NSA paid RSA $10 million in a deal that set Dual EC as the preferred, or default, method for number generation in the BSafe software.

  • NIST:
    • Standardized SP 800-90 in June 2006. Despite the objections from Gjosteen, Schoenmakers, and Sidorenko, this final version of SP 800-90 included Dual EC, with its full bias.
    • That is: intentionally standardized known to be backdoored standard while ignoring and hiding alarms from many security researchers

3 encrypted permament storage from command line

Scan volumes:

sudo lvscan

3.1 encrypted partition

format encrypted partition

sudo cryptsetup luksFormat /dev/<targetPartition>

type: YES

decrypt encrypted partition

sudo cryptsetup luksOpen /dev/<targetPartition> crypt

create filesystem on encrypted partition

sudo mkfs.<filesystemType> /dev/mapper/crypt

3.2 encrypted overlay filesystem

encfs /encrypted/backing/store /unencrypted/mount/point

4 Estonian

4.1 signing algorithms

algorithm usage
  • DigiDocService supports signatures using the ECDSA (Elliptic Curve Digital Signature Algorithm) and RSA algorithms.
  • ECDSA is currently only supported for Mobile-ID.
  • If user's SIM card does not have ECDSA support, RSA algorithm is used.
  • For DDOC file format only RSA is supported.
  • BDOC format supports RSA and ECDSA.
  • A single signer can have multiple active certificates, each with a different signing algorithm. In such cases, DigiDocService chooses the most suitable certificate automatically.
  • For SIM cards that support both ECDSA and RSA the GetMobileCertificate method by default returns the ECDSA certificate; similarly, the MobileSignHash method chooses ECDSA. But starting from version 3.9 it is possible to request ECDSA (ECC) or RSA certificate.

4.2 DigiDocService

The DigiDocService is a SOAP-based web service with the help of which you can easily add identification, digital signature, signature identification and Mobile-ID functionality to an e-service or application. The service can be used on development platforms that have SOAP 1.0 RPC-encoded support.

intro https://sk.ee/en/services/validity-confirmation-services/digidoc-service/
specification http://sertkeskus.github.io/dds-documentation/
namespace URI http://www.sk.ee/DigiDocService/DigiDocService_2_3.wsdl
namespace prefix dig

4.2.2 functionality

  • digital signature using an ID-card (or another smart card);
  • identification and digital signing using Mobile-ID;
  • certificate validity verification (identification using an ID-card or another smart card);
  • creation of DigiDoc files;
  • content and signature validity verification of digitally signed files (DigiDoc).

4.2.3 environments

  1. production
    endpoint https://digidocservice.sk.ee/DigiDocService
    service name <provided by Sertifitseerimiskeskus>
  2. test
    endpoint https://tsp.demo.sk.ee
    service name Testimine

4.2.4 Mobile-ID

  • in Estonian: Mobiil-ID
  1. toimingute käivitamine


    • MobileAuthenticate,
    • MobileSign ja
    • MobileCreateSignature.

    Kõikide nende meetodite puhul on sisendparameetriteks Mobiil-ID kasutaja telefoninumber ja isikukood.

    Kui soovite oma e-teenusesse lubada ka Leedu mobiilioperaatorite Mobiil-ID teenuse kasutajaid siis on mõlema sisendparameetri (isikukood ja telefoninumber) edastamine DigiDocService teenusele kohustuslik. Vastasel juhul Mobiil-ID toimingu algatamine ei õnnestu.

    NB! Eesti mobiilioperaatorite puhul on soovitatav samuti edastada mõlemad sisendparameetrid. Nõue on plaanitud tulevikus muuta kohustuslikuks.

  2. testing
    1. test numbers
      MA MobileAuthenticate status
      GMAS GetMobileAuthenticateStatus
      Tel. nr Isikukood Riik Kirjeldus MA GMAS
      +37200007 14212128025 EE Successful authentication, signing OK USER_AUTHENTICATED
      +37260000007 51001091072 EE Successful authentication, signing OK USER_AUTHENTICATED
      +37200000766 11412090004 EE For auhentication and signing BDOC files new SIM OK USER_AUTHENTICATED
            cards are using ECC prime 256v1 key set and    
            for signing DDOC files RSA 2024 key set.    
      +37200001 38002240211 EE Mobile-ID is not activated E: 303  
      +37200002 14212128020 EE Mobile-ID functionality is not ready yet, OK MID_NOT_READY
            try again after awhile    
      +37200003 14212128021 EE Sending authentication request to phone failed OK SENDING_ERROR
      +37200004 14212128022 EE User canceled authentication OK USER_CANCEL
      +37200005 14212128023 EE Service techical error OK INTERNAL_ERROR
      +37200006 14212128024 EE SIM application error OK SIM_ERROR
      +37200008 14212128026 EE Phone is not in coverage area OK PHONE_ABSENT
      +37200009 14212128027 EE Mobile-ID user certificates are revoked or suspended E: 302  
      +37060000007 51001091072 LT Successful authentication, signing OK USER_AUTHENTICATED
      +37060000001 51001091006 LT Mobile-ID is not activated E: 303  
      +37060000002 51001091017 LT Mobile-ID functionality is not ready yet, OK MID_NOT_READY
            try again after awhile    
      +37060000003 51001091028 LT Sending authentication request to phone failed OK SENDING_ERROR
      +37060000004 51001091039 LT User canceled authentication OK USER_CANCEL
      +37060000005 51001091050 LT Service techical error OK INTERNAL_ERROR
      +37060000006 51001091061 LT SIM application error OK SIM_ERROR
      +37060000008 51001091083 LT Phone is not in coverage area OK PHONE_ABSENT
      +37060000009 51001091094 LT Mobile-ID user certificates are revoked or suspended E: 302  
    2. testing using own phone number

      Mobiil-ID funktsionaalsuse testimiseks vastu Mobiil-ID test serveri:

      • Peab olema kehtiv Mobiil-ID leping ja telefonis Mobiil-ID toega SIM kaart.
      • Rakendus peab olema konfigureeritud kasutama Mobiil-ID test serverit.
      • Mobiil-ID test serverisse peab paigaldama testija Mobiil-ID sertifikaadid.
      1. Sertifikaatide paigaldamine test Mobiil-ID serverisse

        Enda Mobiil-ID autentimise ja allkirjastamise sertifikaadi saab kätte täites vormi addressil: https://demo.sk.ee/MIDCertsReg/mobileIDAuth/

        Saadud sertifikaadid tuleb registreerida järgneval vormil: https://demo.sk.ee/MIDCertsReg/

4.2.5 joining

Teenusele ligipääsu võimaldatakse IP aadressi põhiselt, teenuse kasutamiseks tuleb rakenduse pakkujal sõlmida leping AS Sertifitseerimiskeskusega, teenuse kasutamise maksumus sõltub allkirjastamise ja autentimise päringute arvust kuus ja ühelt rakenduselt tulevatest üheaegsete päringute arvust.

4.3 digitally signed documents

4.3.1 formats

  1. BDOC
    • ZIP container with the signed files, the signatures and the protocol control information and can basically be opened by any program that recognizes the ZIP format.
    • based on ASiC-E standard
    • Signatures
      • stored in XAdES format
      • supports two signature formats: BDOC-TM and BDOC-TS
    1. BDOC-TM
      • Stands for: BDOC with Time Mark.
      • Signature format has time-mark ensuring long-term provability of the authenticity of the signature.
      • This format has been used as a default digital signature format in Estonia since 2015.
      • It is based on XAdES baseline LT signature format.
      • Recommended extension is .bdoc
    2. BDOC-TS/ASiC-E
      • Stands for: BDOC with Time Stamp.
      • In contrast to the BDOC-TM format, long-term provability of the authenticity of the signature is ensured by time-stamps.
      • It is based on XAdES baseline LT signature format and uses RFC3161 based time-stamps which makes it highly compliant in international context.
      • To ensure better compliance with international standards, it's recommended to sign documents with the BDOC-TS time-stamp signature profile.
      • Recommended extension is .asice
  2. DDOC
    • Old format, superseded by BDOC
    • Has ddoc extension.
    • An old DigiDoc digital signature format
    • Since year 2015 it's recommended not to sign documents in the DDOC format
    • It is based on XML Advanced Electronic Signatures (XAdES) format, corresponding to profile XAdES-X-L
    • The DigiDoc container includes the source files (the files that were signed) as well as the signatures that are related to the signed file(s)
    • Every signature contains the certificate, validity confirmation and the validity confirmation service certificate.
  3. compatibility matrix
    • digitally signed documents compatibility matrix.png

4.3.2 libraries

  1. JDigiDoc

    JDigiDoc is a library for manipulating Estonian DDOC and BDOC digital signature container files.

    It offers the functionality for creating digitally signed files in DDOC and BDOC formats, adding new signatures, verifying signatures and adding confirmations in OCSP format.

    DigiDoc documents are XML files based on the international standards XML-DSIG, ETSI TS 101 903 and others. DigiDoc documents and the JDigiDoc library implement a subset of XML-DSIG and ETSI TS 101 903.

    1. releases
  2. DigiDoc4j
    1. Maven

      You can use the library as a Maven dependency from the Maven Central (http://mvnrepository.com/artifact/org.digidoc4j/digidoc4j)


4.4 ID card

Nende teenuste abil saab ehitada nii autentimis- kui ka allkirjastamislahendusi.

Et saaksite olla kindlad teie poolt loodud rakenduste, e-teeninduse ja teiste lahenduste toimimises soovitame teenuseid enne avalikustamist testida erinevate põlvkondade ID-kaartidega. Testkaarte saab tellida Sertifitseerimiskeskusest

4.4.1 test-OCSP teenust aadressil http://demo.sk.ee/ocsp

võimalik kasutada test või päris ID-kaardiga, laadides serdid eelnevalt test teenuse andmebaasi https://demo.sk.ee/upload_cert/

4.4.2 test-DigiDocService'it aadressil https://tsp.demo.sk.ee

  • võimalik kasutada test-telefoninumbreid
  • võimalik kasutada päris Mobiil-IDga, laadides serdid eelnevalt test teenuse andmebaasi https://demo.sk.ee/MIDCertsReg/
  • ei tööta vanemate Elisa Eesti AS mobiil-ID SIM-kaartidega, soovitus kasutada test-testnumbreid.

4.4.3 Kuidas ID-kaardiga autentimine üldse toimib?

Eesti ID kaardi autentsuse kontroll on konfigureeritud veebiserveris toimuma klientide rakendustele nähtamatult ja see toimub sisuliselt nii:

  1. Veebiserver nõuab külastajalt (s.t. tema brauserilt) sertifikaati (kuidas külastaja brauser seda omakorda külastajalt nõuab, sõltub juba konkreetsest brauserist)
  2. Saades kliendi brauserilt sertifikaadi, kontrollib veebiserver järgmist:
  3. sertifikaat PEAB OLEMA signeeritud AS Sertifitseerimiskeskus poolt
  4. sertifikaat EI TOHI OLLA kantud AS Sertifitseerimiskeskus poolt väljastatatud sertifikaatide tühistusnimekirjadesse
  5. Alles nüüd, kui need 2 etappi on edukalt läbitud, näidatakse kaitstud kataloogi sisu või käivitatakse virtuaalserveris PHP rakendus.

4.4.4 test ajatempliteenust

4.4.5 veebilehitsejapõhise allkirjastamise plugini testrakendus

4.4.6 veebis allkirjastamise PHP näidisrakendus http://www.id.ee/index.php?id=30368

  • Mobiil-ID ja ID-kaardiga hashcode režiimis konteinerite edastamine. Näidisrakendus hõlmab konteineri loomist, andmefailide lisamist, eemaldamist, allkirjastamist ID-kaardi ja Mobiil-ID’ga, allkirja eemaldamist ja allkirjade verifitseerimist.
  • toetab DDOC ja BDOC
  • kasutab JavaScripti teeki (hwcrypto.js) allkirjastamisplugina valimiseks.

4.4.7 authentication parameters

  • ssl_client_verify
  • ssl_client_i_dn
  1. ssl_client_s_dn

    Example content:


4.4.8 Erakorraline turvarisk (2017)

  1. probleemi olemus
    • Riski all alates 2014. aasta oktoobrist välja antud ID-kaardid, sealhulgas e-residentidele väljastatud tunnistused.
  2. meetmed
    • ID-kaardi avalike võtmete andmebaas nüüd suletud, kuna ilma avalikku võtit teadmata ei ole võimalik antud turvariski kaardi ründamiseks kasutada.
    • https://github.com/crocs-muni/roca on saadaval kood, mis võimaldab kontrollida, kas esitatud sertifikaat võib olla mõjutatud.
    • Uuendatud ID-kaardi sertifikaatide puhul võetakse kasutusse elliptkõverate krüptograafia NIST P-384 (seni on olnud kasutusel RSA algoritm).
    • Sertifikaadiahel ei muutu ehk sertifikaate väljastatakse endiselt ESTEID-SK 2015 ahelast.
    • Uue profiiliga autentimissertifikaadis kaovad ära võtme kasutusalad (KeyUsage) "Key Encipherment" ja "Data Encipherment", mis asendatakse "Key Agreement" võtmekasutusega. Võtme kasutusalad muutuvad, kuna standard RFC5480 neid ECC võtmete puhul kasutada ei luba.
    • Allkirjastamissertifikaadis võtmekasutuse väärtused ei muutu (kasutuses endiselt "Non-Repudiation").
    • Veebi serveri seadistamine: https://www.id.ee/public/INFRA-Kurvid-191017-1426-18.pdf
    • DigiDoc4j teek toetab elliptkõverate krüptograafiat alates 1.0.4 versioonist, tugi on olemas ka viimases avalikus jdigidoc teegis. Kui on kasutusel uuemad versioonid, siis teadaolevalt ei ole nende teekide kasutajatel muudatusi vaja teha.
  3. Olulisemad piirangud
    • Uuendatud ID-kaardi sertifikaadile ei ole võimalik krüpteerida. Vastav tugi arendatakse hiljem. Selle käigus uuendatakse ka CDOC formaat.
    • Uuendatud ID-kaardiga ei ole võimalik allkirjastada DDOC formaadis faile. Infosüsteemid, kus on veel võimalik DDOC allkirjastamine, peaksid üle minema ASICE formaadile.
    • Uuendatud ID-kaarti saab kasutada ainult uue ID-tarkvara versiooniga, mis on avalikustatud aadressil https://installer.id.ee.
    • Uuendatud ID-kaardi sertifikaadiga ei ole võimalik PDF formaadis allkirjastamine. Vastav piirang on PDF standardi poolel.

4.5 X-Road (X-tee)

  • Note case difference between english and estonian versions, is intentional.

Andmete ülekandeks ja kaugtööna programmide käivitamiseks on kasutusel SOAP protokoll.

Veebiteenuste kirjeldamiseks kasutatakse WSDL keelt ja teenuste kirjeldamiseks UDDI standardit.

4.5.1 functionality

  • Autentimine (sh Riigiportaali eesti.ee kaudu teenuste pakkumisel ID-kaart, mobiil-ID + viis internetipanka)
  • Autoriseerimine
  • Registrite teenused
  • Päringute ärimudeli realiseerimisvahendid (võimalus päringuid esitada mitmetesse eri andmebaasidesse ja registritesse)
  • Võimalus sisestada andmeid registritesse
  • Turvaline andmevahetus, logide salvestamine ja päringute jälitusvõimalus
  • Riigiportaal eesti.ee X-tee päringute esitluskiht
  • Tsentraalne ja lokaalne monitooring
  • X-tee teenusekirjelduste repositoorium RIHAs (WSDL formaadis).

4.5.2 V5

  1. environments
    1. development

      Keskkonnaga võivad liituda kõik, kes soovivad arendada X-tee teenuseid. Liitumiseks tuleb saata sooviavaldus vabas vormis aadressile mailto:help@ria.ee.

      X-tee parameetrid:

      • Liitumiseks tuleb saata sertifikaadipäring e-postiga aadressile mailto:help@ria.ee.
      • Keskserver:
      • DNS võtme autentsuskood: EA:BC:21:E4:6E:5A:98:72:00:3A:AC:71:C1:5F:B8:D6:5A:A7:7C:7F
      • CA võtme autentsuskood: B7:AB:CE:9A:F3:1F:D7:AA:CB:B5:1C:EA:7D:8A:62:20:B8:91:7C:6E
    2. production

      Keskkonda kasutatakse riigi ja erasektori asutuste ja infosüsteemide (andmekogude) vaheliseks andmevahetuseks.

      Andmevahetus käib reaalsete andmetega.

      Liitumine RIHA kaudu.

      X-tee parameters:

      Keskserver (v5)
      Keskserver (v5)
      Keskserver (v5)
      DNS võtme autentsuskood (v5) 0b:64:d4:68:3d:f0:4b:7a:98:a5:b5:5b:01:62:eb:cf:92:60:7f:5b
      CA võtme autentsuskood A6:3E:52:9D:F6:A6:97:60:DD:30:CE:E2:FB:B9:EA:B9:C9:6F:78:13
    3. test

      Keskkonda kasutatakse toodangusse minevate teenuste testimiseks.

      Vastavalt VV määruse Infosüsteemide andmevahetuskiht 15 lg 3 punktile 4 peavad kõik toodangukeskkonnaga liitunud andmekogud hoidma oma andmekogu ka testandmetega testkeskkonnas. https://www.riigiteataja.ee/akt/12956835?leiaKehtiv

      Kasutajad on RIHAs registreeritud asutused ja andmekogud.

      Andmevahetus käib testandmetega.

      Liitumine RIHA kaudu.

      X-tee parameetrid:

      DNS võtme autentsuskood 93:B3:78:25:A1:5F:38:6C:20:59:57:87:4C:48:C3:94:C3:F9:C6:BA
      CA võtme autentsuskood 05:E7:B1:3A:2D:55:7C:9C:5A:8A:35:CD:92:FB:67:4F:EF:3D:97:78
  2. security server

    Turvaserver töötab operatsioonisüsteemil Ubuntu Server 10.04 Long-Term Support (LTS). Toetatud on nii 32- kui ka 64-bitine platvorm. Turvaserver tarnitakse .deb-pakkidena, mis on kättesaadavad ametlikust X-tee repositooriumist.

    Ametlik repositoorium:

    1. firewall setup

      Incoming connections:

      TCP 5555 turvaserverite-vaheline SSL/TLS andmevahetus.

      Outgoing connections:

      TCP 25 SMTP, e-posti (sh tõrketeadete) saatmine Internetti;
      TCP 37 UNIX'i time protokoll diagnostikasüsteemi tarbeks;
      TCP ja UDP 53 nimeserveri teenused;
      TCP 80 HTTP, keskserveri võtmete laadimine;
      UDP 123 NTP, turvaserveri kella sünkroniseerimine;
      TCP 5555 turvaserverite-vaheline SSL/TLS andmevahetus;
      TCP 5556 turvaserveri päringute sõnumilühendite logimisprotokoll;
      UDP 6666 jälgimisjaamadele teabe saatmine (uus SKIP/ESP protokoll,
        kasutuses alates X-tee versioonist 5.0)
    2. hardware requirements

      Recommended configuration:

      Server üldiselt peab olema Ubuntu 10.04 poolt toetatud (emaplaat, protsessor, võrgukaardid, salvestussüsteem, graafikakaart);

      CPU 64-bitine Intel or AMD
      RAM 1 GB
      network card 100 Mbps
      USB 1 vaba pesa mälupulga jaoks

4.5.3 V6

  1. specifications
    1. RT I, 27.09.2016, 4: Vabariigi Valitsuse määrus: Infosüsteemide andmevahetuskiht
      Väljaandja Vabariigi Valitsus
      Akti liik määrus
      Teksti liik algtekst-terviktekst
      Redaktsiooni jõustumise kp 30.09.2016
      Redaktsiooni kehtivuse lõpp  
      Avaldamismärge RT I, 27.09.2016, 4
      Vastu võetud 23.09.2016 nr 105

      Määrus kehtestatakse avaliku teabe seaduse § 43^9 lõike 1 punkti 5 alusel.

      1. 1. peatükk Üldsätted
        1. § 1. Kohaldamisala

          (1) Määrusega kehtestatakse nõuded infosüsteemide andmevahetuskihile, selle kasutamisele ja haldamisele.

          (2) Määrust ei kohaldata riigisaladust või salastatud välisteavet sisaldava infosüsteemi suhtes.

        2. § 2. Terminid

          () Määruses kasutatakse termineid järgmises tähenduses:

          1. infosüsteemide andmevahetuskiht (edaspidi X-tee) on tehniline infrastruktuur ja keskkond X-tee liikmete vahel, mis võimaldab turvalist ja tõestusväärtust tagavat internetipõhist andmevahetust;
          2. X-tee liige on asutus või isik, kes on liitunud X-teega;
          3. keskus on Riigi Infosüsteemi Amet, kes vastutab X-tee haldamise ja arendamise eest;
          4. andmeteenus on X-tee liikme teenus, mille kaudu toimub internetipõhine andmevahetus;
          5. andmeteenuse osutaja on X-tee liige, kes osutab teistele liikmetele andmeteenust;
          6. andmeteenuse kasutaja on X-tee liige, kes kasutab andmeteenust;
          7. andmeteenuse vahendaja on X-tee liige, kes võimaldab enda organisatsiooni välisele füüsilisele või juriidilisele isikule juurdepääsu andmeteenusele oma infosüsteemi vahendusel;
          8. andmeteenuse lõppkasutaja on füüsiline isik, kes kasutab andmeteenust X-tee liikme infosüsteemi vahendusel;
          9. sõnum on vormindatud andmete kogum, mida vahetatakse andmeteenuse osutaja ja kasutaja vahel X-tee kaudu;
          10. alamsüsteem on tehnoloogiliselt ja organisatoorselt piiritletud X-tee liikme infosüsteemi osa andmeteenuse osutamiseks või kasutamiseks;
          11. pääsuõigus on andmeteenuse kasutamise võimaldamine X-tee tarkvaras;
          12. X-tee baasprotokollistik on reeglite kogum, mis tagab turvalise andmevahetuse toimimise arvutivõrgu kaudu;
          13. turvaserver on tarkvaraline lahendus, mis järgib X-tee baasprotokollistikku;
          14. X-tee sõnumiprotokoll on X-tee baasprotokollistiku osa, mis võimaldab X-tee liikmetel sõnumeid töödelda;
          15. e-tempel on elektrooniliste andmete kogum, mis vastab Euroopa Parlamendi ja nõukogu määruses (EL) nr 910/2014 e-identimise ja e-tehingute jaoks vajalike usaldusteenuste kohta siseturul ja millega tunnistatakse kehtetuks direktiiv 1999/93/EÜ (ELT L 257, 28.08.2014, lk 73–114) (edaspidi Euroopa Parlamendi ja nõukogu määrus (EL) nr 910/2014) sätestatud täiustatud või kvalifitseeritud e-templi nõuetele;
          16. päringulogi on X-tee baasprotokollistikule tuginev turvaserveri osa, kuhu salvestatakse e-templiga kinnitatud X-teel vahetatud sõnumid.
      2. 2. peatükk X-tee haldamine
        1. § 3. X-tee haldamise põhimõtted

          () X-tee haldamisel järgitakse järgmisi põhimõtteid:

          1. sõltumatus platvormist ja arhitektuurist – X-tee võimaldab tarkvaraplatvormil oleval X-tee liikmel suhelda infosüsteemi vahendusel tarkvaraplatvormil oleva andmeteenuse osutajaga;
          2. multilateraalsus – X-tee liikme võimalus taotleda juurdepääsu kõigile X-tee kaudu osutatavatele andmeteenustele;
          3. avatus ja standardiseeritus – X-tee haldamisel ja arendamisel kasutatakse võimaluse korral rahvusvahelisi standardeid ja protokolle;
          4. turvalisus – X-tee kaudu andmete vahetamisel ei muutu andmete terviklus, käideldavus ja konfidentsiaalsus.
        2. § 4. Keskuse ülesanded

          (1) Keskus:

          1. haldab nii toodangu- kui ka testkeskkonnas X-tee liikmete, X-teel registreeritud turvaserverite ja X-teega liitunud alamsüsteemides olevat infot, mis tagavad X-tee turvalise andmevahetuskanali loomiseks ja andmeteenuste kasutamiseks vajaliku informatsiooni kättesaadavuse X-tee liikme turvaserverile;
          2. korraldab liikmesust, alamsüsteemi ja turvaserverit puudutavate taotluste menetlemist;
          3. töötab välja X-teega liitumise ja selle kasutamise tingimused ning avalikustab need keskuse veebilehel;
          4. tagab X-tee kasutamise võimaluse;
          5. seirab X-tee kasutamist ja kogub kasutusstatistikat;
          6. käsitleb turvaintsidente;
          7. piirab X-tee liikme õigusi käesolevas määruses sätestatud juhtudel;
          8. nõustab X-tee liiget X-teega seotud küsimustes;
          9. teavitab X-tee liiget muudatustest X-tee haldamises või kasutamises ning kõigist teadaolevatest X-tee kasutamist takistavatest asjaoludest või hooldustöödest, edastades e-kirja riigi infosüsteemi haldussüsteemis (edaspidi RIHA) märgitud X-tee liikme kontaktidele;
          10. haldab ja korraldab Eesti X-tee keskkonna ühendamist teiste andmevahetuskeskkondadega;
          11. tagab standardiseeritud turvaserveri tarkvara tasuta kättesaadavuse X-tee liikmele;
          12. tagab füüsilisest isikust andmeteenuse lõppkasutajale mõeldud alamsüsteemi standardlahenduse X-tee sõnumiprotokollile vastavuse ja tarkvara tasuta kättesaadavuse X-tee liikmele;
          13. valmistab ette ja viib ellu X-tee infrastruktuuri arendusprojekte ja tagab X-tee arhitektuurse tervikluse;
          14. peatab § 14 lõikes 3 nimetatud juhul andmeteenuse kasutamiseks vajaliku informatsiooni kättesaadavuse X-tee liikme turvaserverile;
          15. haldab ja arendab X-tee platvormi toimimise tagamiseks liikmete ja usaldusteenuse registreerimiseks ning monitooringu toimimiseks tarvilikke lahendusi.

          (2) Keskus on lõike 1 punktis 9 ette nähtud teavitamiskohustuse täitmisel kohustatud järgima järgmisi etteteatamise tähtaegasid:

          1. X-tee haldamises või kasutamises toimuvast muudatusest või planeeritud hooldustööst teavitatakse üks kuu ette;
          2. X-tee haldamises ja kasutamises toimuvast erakorralisest muudatusest ning planeerimata hooldustööst teavitamisel on keskusel õigus järgida punktis 1 nimetatud tähtajast lühemat etteteatamise tähtaega;
          3. muudatusest X-tee baasprotokollistikus või X-tee sõnumiprotokollis, mis tingivad muudatusi X-tee liikme alamsüsteemis või andmeteenuses, teavitatakse 18 kuud ette.
      3. 3. peatükk X-tee kasutamine
        1. § 5. X-teega liitumine ja selle liikmesus

          (1) X-teega liitumist taotletakse RIHA kaudu.

          (2) X-teega liitumisel sõlmib taotleja keskusega liitumiskokkuleppe. Liitumiskokkuleppes fikseeritakse poolte õigused, kohustused ja vastutus.

          (3) X-tee liikmel on õigus kasutada X-teed käesoleva määruse ja liitumiskokkuleppega ette nähtud korras.

          (4) X-tee liige on kohustatud:

          1. tagama X-teega liitumise korral oma infosüsteemi järjepidevuse, haldamise, arendamise ning turvalise ja häireteta töö;
          2. võtma kasutusele §-s 7 sätestatud turvalise ja standardiseeritud andmevahetuse tagamise elemendid ning kohandama oma infosüsteemi tööks X-tee keskkonnas;
          3. rakendama turvalisusega seotud riskide maandamiseks andmete terviklust, konfidentsiaalsust ja käideldavust tagavaid meetmeid ning tagama rakendatavate meetmete sõltumatu auditeerimise vähemalt iga nelja aasta järel;
          4. täitma keskuse edastatud korraldusi;
          5. hoidma RIHA-s enda kohta käivaid andmeid ajakohasena;
          6. teavitama keskust viivitamata X-tee kasutamisega seonduvast probleemist ja asjaolust, mis võib mõjutada keskuse või X-tee liikme kohustuste täitmist;
          7. teavitama viivitamata keskuse intsidentide käsitlemise osakonda turvaintsidendist ja selle vahetust ohust;
          8. edastama X-teega seotud taotlused ning punktis 6 nimetatud teabe keskusele RIHA kaudu või selle võimatusel elektronpostiga;
          9. esitama keskuse nõudmisel turvaserveri turvalisuse hindamiseks vajaliku teabe, turvaeeskirjad ning rakendatud meetmete rakendamise kirjelduse.

          (5) Riigi ja kohaliku omavalitsuse üksuse andmekogu pidamisel lähtub X-tee liige käesoleva paragrahvi lõike 4 punktis 3 sätestatud meetmete rakendamisel ning rakendatavate meetmete sõltumatu auditeerimise tagamisel avaliku teabe seaduse § 43^9 lõikes 3 sätestatud erisustest.

        2. § 6. X-teega liitumisest keeldumine

          () Keskusel on õigus jätta X-teega liitumise taotlus rahuldamata, kui:

          1. taotlejal puudub unikaalne tunnus, millele on võimalik väljastada keskuse veebilehel avalikustatud nõuetele vastavat e-templi sertifikaati;
          2. taotleja ei ole keskuse nõudmisel esitanud esindusõiguse tuvastamiseks vajalikke dokumente või taotluse esitajal puudub esindusõigus taotluse esitamiseks;
          3. taotleja liitumisel esitatud andmed ei ole RIHA-s registreeritud või andmed ei ole ajakohased;
          4. taotleja või tema infosüsteem ei vasta käesolevas määruses esitatud muudele nõuetele või X-tee toimimise põhimõtetele.
        3. § 7. Turvalise ja standardiseeritud andmevahetuse tagamise elemendid

          () Turvaline ja standardiseeritud andmevahetus X-teel on tagatud kõigi järgmiste tingimuste täitmisel:

          1. turvalise andmevahetuskanali loomise kaudu vastavalt §-le 8;
          2. e-templiga andmevahetuse tervikluse tagamise kaudu vastavalt §-le 9;
          3. alamsüsteemi defineerimise kaudu vastavalt §-le 10;
          4. ühtlustatud andmeteenuse osutamise nõuete kaudu vastavalt §-le 11;
          5. andmeteenuse kasutaja kindlaksmääramisel andmeteenuse kasutamise kokkuleppe ja pääsuõiguse andmise kaudu vastavalt §-le 12.
        4. § 8. Turvalise andmevahetuskanali loomine

          (1) X-tee liige peab X-tee turvalise andmevahetuskanali loomise võimaldamiseks paigaldama turvaserveri tarkvara infosüsteemi ning registreerima keskuses turvaserveri autentimissertifikaadi, mis peab vastama keskuse veebilehel avaldatud nõuetele.

          (2) X-teel on lubatud kasutada vaid sellist turvaserveri tarkvara, mis järgib keskuse kinnitatud X-tee baasprotokollistikku.

          (3) Turvaserveri kasutamisel on X-tee liige kohustatud:

          1. tagama e-templiga kinnitatud X-teel vahetatud sõnumite päringulogi olemasolu ja päringulogi arhiveerimise korral töötama välja päringulogi arhiveerimise protseduuri, mis sisaldab arhiveerimise sagedust ning arhiveeritava informatsiooni loetelu;
          2. määrama isikud, kes ja millistel tingimustel saavad päringulogi arhiveerimise korral juurdepääsu turvaserveri arhiveeritud päringulogile;
          3. päringulogi arhiveerimisel tagama arhiveeritud sõnumite töötlemisel samad konfidentsiaalsuse nõuded, mis on nõutud andmeteenuse kasutamiseks;
          4. majutama turvaserverit Eesti Vabariigi jurisdiktsiooni all oleval territooriumil.

          (4) Keskuse pakutava turvaserveri kasutamisel on X-tee liige lisaks lõikes 3 nimetatud kohustuste täitmisele kohustatud:

          1. kasutama turvaserveri tarkvara vastavalt juhistele, mis on avalikustatud keskuse veebilehel;
          2. uuendama turvaserveri tarkvara hiljemalt kaks kuud pärast keskuse poolt tarkvarauuenduste kättesaadavaks tegemist.

          (5) Turvaserverit võib majutada väljaspool Eesti Vabariigi jurisdiktsiooni all olevat territooriumit üksnes keskuse loal, kui X-tee liige:

          1. tagab § 5 lõikes 4 sätestatud kohustuste täitmise;
          2. rakendab turvalisusega seotud riskide maandamiseks andmete terviklust, konfidentsiaalsust ja käideldavust tagavaid meetmeid ning tagab rakendatavate meetmete sõltumatu auditeerimise vähemalt iga kahe aasta järel.

          (6) X-tee liige peab oma turvaserveri jagamisel teisele X-tee liikmele kasutama krüpteeritud ühendust ning kahepoolset autentimist turvaserveri ja alamsüsteemi ühendamiseks.

        5. § 9. Andmevahetuse tervikluse tagamine e-templiga

          (1) Andmevahetuse terviklus ning X-teel vahetatud sõnumi ja X-tee liikme seose tuvastamine tagatakse e-templiga, mille loomiseks on X-tee liige kohustatud turvaserveris kasutama järgmisi Euroopa Parlamendi ja nõukogu määruse (EL) nr 910/2014 nõuetele vastavaid usaldusteenuseid:

          1. sertifitseerimise teenus, mille kaudu väljastatakse e-templi kvalifitseeritud sertifikaat;
          2. sertifikaadi kehtivuskinnituse teenus;
          3. ajatempliteenus.

          (2) X-teel moodustunud e-tempel on kehtiv, kui kasutatud sertifikaadi kehtivuskinnituse ja ajatempli ajavahe ei ole rohkem kui kaheksa tundi.

          (3) X-tee liikmel on keelatud töödelda X-teel vahetatud andmeid, mida ei ole võimalik kinnitada lõikes 1 nimetatud e-templiga.

        6. § 10. X-teega liidestatud alamsüsteem

          (1) X-teel on võimalik kasutada ja osutada teenust vaid sellisel alamsüsteemil, mis on keskuses registreeritud.

          (2) Alamsüsteemi X-teel registreerimiseks esitab X-tee liige keskusele taotluse RIHA kaudu.

          (3) X-teel on võimalik registreerida vaid sellist alamsüsteemi:

          1. mis on kantud RIHA-sse;
          2. millele on määratud alamsüsteemi toimimise eest vastutav füüsiline isik ja alamsüsteemi teenindava turvaserveri administraatori kontaktandmed;
          3. mille suhtes rakendatakse turvalisusega seotud riskide maandamiseks andmete terviklust, konfidentsiaalsust ja käideldavust tagavaid meetmeid ning tagatakse rakendatavate meetmete sõltumatu auditeerimine vähemalt iga nelja aasta järel, lähtudes § 5 lõikes 5 sätestatud erisustest.

          (4) X-tee liige on alamsüsteemi registreerimise järel kohustatud:

          1. määrama töö- ja ametikohad, kellel on õigus alamsüsteemi ja seeläbi alamsüsteemile võimaldatud andmeteenuseid kasutada, ning lubama organisatsioonisiseselt juurdepääsu vaid selleks õigustatud isikutele;
          2. tagama X-teega liidestatud alamsüsteemi turvalise ja häireteta töö ning vastavuse X-tee liikmete vahelisele andmeteenuse kasutamise kokkuleppele.

          (5) Keskusel on õigus alamsüsteemi registreerimise taotlus tagasi lükata või registreeritud alamsüsteem registrist kustutada, kui mõni lõigetes 3 ja 4 esitatud nõue on täitmata.

        7. § 11. Nõuded andmeteenusele

          () Andmeteenus peab:

          1. vastama keskuse kehtestatud X-tee sõnumiprotokollile;
          2. olema registreeritud RIHA-s koos keskuse nõuetele vastava ning aja- ja asjakohase andmeteenuse kirjeldusega ja sisaldama informatsiooni andmeteenuse kasutamiseks vajalike turvameetmete kohta, arvestades andmeteenuses sisalduvate andmete koosseisu ning andmeteenuse iseloomu;
          3. olema kasutatav ka X-tee testkeskkonnas.
        8. § 12. Andmeteenuse osutamine ja kasutamine

          (1) Andmeteenust osutatakse ja kasutatakse vastavalt X-tee liikmete vahelisele andmeteenuse kasutamise kokkuleppele. Andmeteenuse kasutamise kokkuleppes määratakse kindlaks:

          1. andmeteenuse kasutamiseks vajalikud infoturbemeetmed ning andmeteenuse kasutaja alamsüsteemilt nõutavad organisatsioonilised, füüsilised ja infotehnilised turvameetmed, arvestades töödeldavate andmete koosseisu ning õigusaktidega ettenähtud nõudeid;
          2. andmeteenuse kolmandale isikule vahendamise luba vastavalt §-le 13;
          3. teenustaseme tingimused.

          (2) Andmeteenuse osutaja on kohustatud:

          1. registreerima andmeteenuse koos andmeteenuse tehnilise kirjeldusega turvaserveris ja hoidma andmeteenuse kirjelduse nii turvaserveris kui ka RIHA-s asja- ja ajakohasena;
          2. andmeteenuse kasutajaga kokkuleppe sõlmimise eel veenduma, kas andmeteenuse kasutaja rakendab turvalisusega seotud riskide maandamiseks piisavaid andmete terviklust, konfidentsiaalsust ja käideldavust tagavaid meetmeid;
          3. tagama X-tee süsteemi pääsuõiguse kooskõla X-tee liikmete vahelise andmeteenuse kasutamise kokkuleppega.

          (3) Andmeteenuse kasutamine on võimalik X-tee liikme alamsüsteemis, millele on antud konkreetse andmeteenuse kasutamiseks pääsuõigus.

          (4) Andmeteenuse kasutaja ja osutaja on kohustatud:

          1. järgima andmeteenuse kasutamise kokkulepet;
          2. siduma turvaserverisse laekunud sõnumid ajatempliga.

          (5) X-tee liige tagab oma infosüsteemi kaudu andmeteenuse osutamisel või kasutamisel osaleva lõppkasutaja autentimise ja autoriseerimise.

        9. § 13. Andmeteenuse vahendamine

          (1) X-tee liige võib võimaldada alamsüsteemile ligipääsu organisatsioonivälisele füüsilisele või juriidilisele isikule vaid juhul, kui:

          1. X-tee liige on koostanud ja avalikustanud andmeteenuse vahendamise korra vastavalt lõikele 2;
          2. X-tee liige on end andmeteenuse vahendajana X-teel registreerinud;
          3. andmeteenuse vahendamise luba on fikseeritud X-tee liikmete vahelises andmeteenuse kasutamise kokkuleppes.

          (2) Andmeteenuse vahendamise kord peab sisaldama:

          1. andmeteenuse vahendamise alust;
          2. andmeteenust kasutava alamsüsteemi vahendatu autentimise ja autoriseerimise korda;
          3. andmeteenust kasutava alamsüsteemi vahendatu autentimise ja autoriseerimise logi arhiveerimise korda ja logi säilitamise tähtaega;
          4. X-tee päringulogi arhiveerimise ning arhiivile juurdepääsu korda ja säilitamise tähtaega.

          (3) X-tee liige on andmeteenuse vahendajana kohustatud:

          1. järgima enda kehtestatud andmeteenuse vahendamise korda;
          2. teavitama keskust ja andmeteenuse osutajat, kelle andmeteenuse kasutamiseks on vahendajal pääsuõigus, andmeteenuse vahendamise korra muutumisest;
          3. lähtuma lõike 1 punktis 3 nimetatud kokkulepetes kindlaks määratud pooltevahelistest õigustest ja kohustustest ning veenduma andmeteenuse vahendamise lubatavuses;
          4. avaldama andmeteenuse pakkujale alamsüsteemi vahendatud osaliste andmed vastavalt X-tee baasprotokollistikule.
        10. § 14. X-tee liikmesuse lõppemine

          (1) X-tee liikmel on igal ajal õigus liikmesus üles öelda, esitades keskusele vastavasisulise kirjaliku avalduse.

          (2) Kui lõikes 1 nimetatud avalduses ei ole märgitud X-tee liikmesuse lõppemise tähtpäeva, lõpeb liikmesus eelnimetatud avalduse kättesaamisele järgnevast tööpäevast.

          (3) Keskusel on õigus liikmesus kohe lõpetada või piirata liikmesusest tulenevaid õigusi või anda tähtaeg puuduse kõrvaldamiseks, kui:

          1. X-tee liige rikub käesolevas määruses, liitumiskokkuleppes või andmeteenuse vahendamise korras sätestatud tingimusi;
          2. X-tee liige on esitanud vale- või puudulikke andmeid.

          (4) Keskusel on õigus liikmesus lõpetada, teavitades X-tee liiget elektronposti teel 30 kalendripäeva ette.

      4. 4. peatükk Rakendussätted
        1. § 15. Andmevahetuse tervikluse e-templiga tagamise erisused

          (1) Andmeteenuse osutaja on kohustatud tagama § 9 lõikes 1 nimetatud andmevahetuse tervikluse e-templiga alates 2. jaanuarist 2017. a.

          (2) Andmeteenuse kasutaja on kohustatud tagama § 9 lõikes 1 nimetatud andmevahetuse tervikluse e-templiga alates 2. juunist 2017. a.

        2. § 16. X-tee tarkvara levitamine

          () X-tee tarkvara levitatakse vastavalt tarkvara vaba kasutuse litsentsile MIT (the MIT License).

        3. § 17. Määruse kehtetuks tunnistamine

          () Vabariigi Valitsuse 24. aprilli 2008. a määrus nr 78 ,,Infosüsteemide andmevahetuskiht” tunnistatakse kehtetuks.

        4. § 18. Paragrahvi 9 lõigete 2 ja 3 jõustumine

          () Paragrahvi 9 lõiked 2 ja 3 jõustuvad 2. juunil 2017. a.

      5. seotud isikud
        • Taavi Rõivas
        • Peaminister
        • Kristen Michal
        • Majandus- ja taristuminister
        • Heiki Loot
        • Riigisekretär
  2. example requests/responses
    1. request / response
      1. request
        <?xml version="1.0" encoding="UTF-8"?>
            <xrd:client id:objectType="MEMBER">
            <xrd:service id:objectType="SERVICE">
            <ns1:getRandom xmlns:ns1="http://consumer.x-road.ee">
      2. response
        <?xml version="1.0" encoding="UTF-8"?>
            <xrd:client id:objectType="MEMBER">
            <xrd:service id:objectType="SERVICE">
            <tns:getRandomResponse xmlns:tns="http://producer.x-road.ee">
    2. request with attachment
      MIME-Version: 1.0
      Content-Type: multipart/related; boundary=MIME_boundary; type=text/xml
      Content-Type: text/xml; charset=UTF-8
      Content-Transfer-Encoding: 8bit
      <?xml version="1.0" encoding="UTF-8"?>
          <xrd:client id:objectType="MEMBER">
          <xrd:service id:objectType="SERVICE">
          <ns1:submitData xmlns:ns1="http://consumer.x-road.ee">
            <description href="description.txt"/>
            <data href="cid:data.bin"/>
      Content-Type: text/plain; charset=UTF-8
      Content-Location: description.txt
      this request contains base64 encoded binary data
      Content-Type: application/octet-stream
      Content-Transfer-Encoding: base64
      Content-Id: <data.bin>
  3. community
  4. regulations
    1. joining X-Road

      Asutuse allkirjaõiguslik esindaja peab registreerima liituja RIHAs. Seal saab ta määrata inimesed, kes liitumist tehniliselt korraldama hakkavad.

      Liituja peab tutvuma Infosüsteemide andmevahetuskihi rakenduse määrusega.

      Liituja peab nõustuma RIHAs X-tee liitumistingimustega. See on edaspidise koostöö alus.

      Siin on ametlikud õpetused:

    2. Turvaserveri seadistamine
    3. X-tee alamsüsteemi registreerimine
  5. DVK ja ADIT asutuste X-tee V6 info
      DVK ADIT
    member code 70006317 70006317
    subsystem code dhl adit
  6. X-tee v6 näitepäring DVK süsteemi
    • POST /cgi-bin/consumer_proxy HTTP/1.0
    • Content-Type: text/xml; charset=utf-8
    • Accept: application/soap+xml, application/dime, multipart/related, text/*
    • User-Agent: Axis/1.4
    • Host:
    • Cache-Control: no-cache
    • Pragma: no-cache
    • SOAPAction: "http://producers.dhl.xtee.riik.ee/producer/dhl/receiveDocuments"
    • Content-Length: 1260
    <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
        <xrd:client id:objectType="SUBSYSTEM">
          <id:xRoadInstance>EE</id:xRoadInstance>       <!-- X-tee TEST keskkonnas on siin hoopis: "ee-test"  -->
          <id:memberCode>{SIIA TULEB PÄRINGUT SAATVA ASUTUSE REGISTRIKOOD}</id:memberCode>
          <id:subsystemCode>{SIIA TULEB PÄRINGUT SAATVA ASUTUSE X-TEE ALAMSÜSTEEMI NIMI}</id:subsystemCode>
      <xrd:service id:objectType="SERVICE">
    <xrd:id>{SIIA TULEB SUVALINE UNIKAALNE ID, NÄITEKS: f640123-e69f-408c-8f51-321f65f44cb5}</xrd:id>
            <arv xsi:type="xsd:integer">10</arv>
  7. X-tee kogukond

5 file extensions

5.1 asice

5.2 bdoc

  • Digitally signed document in BDOC format using BDOC-TM subvariant.

5.3 ber

5.4 cacerts

Java KeyStore formatted file.

5.5 cer

  • PEM or DER formatted certificate.
  • Is recognized by Windows Explorer as a certificate, which .pem is not.

5.6 cert

A PEM or DER formatted certificate file with a different extension, one that is recognized by Windows Explorer as a certificate, which .pem is not.

5.8 crt

  • PEM or DER formatted certificate.
  • Is recognized by Windows Explorer as a certificate, which .pem is not.

5.9 csr

5.10 ddoc

  • Digitally signed document in DDOC format.

5.11 der

  • DER formatted file.
  • File content is binary.

5.12 jks

Java KeyStore formatted file.

5.13 key

This is a pem formatted file containing just the private-key of a specific certificate. In Apache installs, this frequently resides in


The rights on this directory and the certificates is very important, and some programs will refuse to load these certificates if they are set wrong.

5.14 p12

5.15 p7b

5.16 p7c

5.17 p7m

  • PKCS #7 encrypted or opaque signature.

5.18 p7s

5.19 pem

  • PEM formatted file.
  • File content is base64 encoded.

5.20 pfx

5.21 pfx

  • Microsoft's "PFX" has received heavy criticism of being one of the most complex cryptographic protocols.
  • binary format

5.22 pub

OpenSSH compatible public-key.

5.23 xkms

  • XKMS formatted file.

6 file formats

6.1 ASN.1 - Abstract Syntax Notation One

The OSI's language for specifying abstract objects is called ASN.1 (Abstract Syntax Notation One, defined in X.208). ASN.1 is a meta language that looks like this.

An ASN.1 data type used to represent certificates:

Certificate                 ::= SIGNED { SEQUENCE {
    version                 [0] Version DEFAULT v1,
    serialNumber                CertificateSerialNumber,
    signature                   AlgorithmIdentifier,
    issuer                      Name,
    validity                    Validity,
    subject                     Name,
    subjectPublicKeyInfo        SubjectPublicKeyInfo,
    issuerUniqueIdentifier  [1] IMPLICIT UniqueIdentifier OPTIONAL,
                                -- if present, version shall be v2 or v3
    subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL,
                                -- if present, version shall be v2 or v3
    extensions              [3] Extensions OPTIONAL
                                -- If present, version shall be v3 -- } }
    Version                 ::=     INTEGER { v1(0), v2(1), v3(2) }
    CertificateSerialNumber ::=     INTEGER
AlgorithmIdentifier         ::=     SEQUENCE {
algorithm                   ALGORITHM.&id ({SupportedAlgorithms}),
parameters                  ALGORITHM.&Type ({SupportedAlgorithms}{ @algorithm})
-- Definition of the following information object set is deferred, perhaps to standardized
-- profiles or to protocol implementation conformance statements.
The set is required
-- specify a table constraint on the parameters component of AlgorithmIdentifier.
-- SupportedAlgorithms      ALGORITHM ::= { ...
Validity                    ::= SEQUENCE {
    notBefore                   Time,
    notAfter                    Time }
SubjectPublicKeyInfo        ::= SEQUENCE {
    algorithm                   AlgorithmIdentifier,
    subjectPublicKey            BIT STRING }
Time ::= CHOICE {
    utcTime                     UTCTime,
    generalizedTime             GeneralizedTime }
Extensions                  ::= SEQUENCE OF Extension
Extension                   ::= SEQUENCE {
    extnId                      EXTENSION.&id ({ExtensionSet}),
    critical                    BOOLEAN DEFAULT FALSE,
    extnValue                   OCTET STRING
                                -- contains a DER encoding of a value of type &ExtnType
                                -- for the extension object identified by extnId -- }
ExtensionSet    EXTENSION   ::= { ...

6.2 BER - Basic Encoding Rules

  • see: ber file

Once you have defined your abstract thing, you need to store it. Dumping this text to a file takes up a lot of space, and these standards were written decades ago when disk space was expensive. OSI came up with a much more machine friendly format called BER (Basic Encoding Rules, defined in X.209), a set of rules for representing ASN.1 objects as strings of ones and zeros. BER describes how to represent or encode values of each ASN.1 type as a string of eight-bit octets. BER is designed to be flexible. There is generally more than one way to BER-encode a given value.

BER encoding of the BIT STRING value "011011100101110111":

BER octets encoding type
03 04 06 6e 5d c0 DER encoding
03 04 06 6e 5d e0 padded with "100000"
03 81 04 06 6e 5d c0 long form of length octets
23 09 03 03 00 6e 5d 03 02 06 c0 constructed encoding: "0110111001011101" + "11"

6.3 CSR - Certificate Signing Request

Some applications can generate these for submission to certificate authoritys.

It includes some/all of the key details of the requested certificate such as subject, organization, state, whatnot, as well as the public key of the certificate to get signed.

These get signed by the CA and a certificate is returned. The returned certificate is the public certificate, which itself can be in a couple of formats.

6.4 DER - Distinguished Encoding Rules (binary)

  • It is basically a list of attributes and values.
  • A way to encode ASN.1 syntax.
  • A DER file is often translated into a PEM - Privacy Enhanced Email (base64) file. PEM translation turns binary data into text characters, which is handy for sending in e-mails and copying and pasting.
  • see: der file

A simpler set of rules were created called the Distinguished Encoding Rules (DER). DER is a subset of BER. It gives a unique encoding to each ASN.1 value.

Putting all this together for the attribute and value countryName = "US" , you get this sequence. CountryName is defined as an attribute type in the X.520 standard. The attribute definition of countryName is written in ASN.1 like this: countryName OBJECT IDENTIFIER ::= { attributeType 6 }. Encoding this attribute and the value US into DER format you end up with a load of unfriendly octets like this: 06 03 55 04 06 13 02 55 53.

DER encoding of the BIT STRING value "011011100101110111"

DER octets encoding type
03 04 06 6e 5d c0 DER encoding

6.4.1 can contain

Any of the following:

6.5 Java KeyStore

Repository of security certificates – either authorization certificates or public key certificates – plus corresponding private keys, used for instance in SSL encryption.

6.5.1 operations on a file

  1. change a keystore password
    keytool -storepasswd -new <newStorepass> -keystore <myKeyStore>.jks -storepass password
  2. change a private key password
    keytool -keypasswd -alias client -keypass <oldPassword> -new <newPassword> -keystore <myKeyStore>.jks -storepass password
  3. check a particular keystore entry using an alias
    keytool -list -v -keystore <myKeyStore>.jks -storepass <myKeyStorePassword> -alias mydomain
  4. check a stand-alone certificate
    keytool -printcert -v -file mydomain.crt
  5. convert to PKCS #12
    keytool -v -importkeystore -srckeystore <source.jks> -srcalias <privateKeyAlias> -destkeystore <target.p12> -deststoretype PKCS12
    • I have no idea why you have to specify private key alias.
    • To find private key alias: list certificates in the Java keystore
    • If you don't specify private key alias, it will export same stuff anyway. But will prompt with errors like:

      Problem importing entry for alias root: java.security.KeyStoreException: TrustedCertEntry not supported.
      Entry for alias root not imported.
      Do you want to quit the import process? [no]:
      Problem importing entry for alias intermediate: java.security.KeyStoreException: TrustedCertEntry not supported.
      Entry for alias intermediate not imported.
      Do you want to quit the import process? [no]:

      • No idea, why such stupid behavior….
  6. delete a certificate
    keytool -delete -alias mydomain -keystore <myKeyStore>.jks -storepass <myKeyStorePassword>
  7. export private key
  8. export a certificate
    keytool -export -alias mydomain -file mydomain.crt -keystore <myKeyStore>.jks -storepass <myKeyStorePassword>
  9. generate a certificate signing request (CSR) for an existing Java keystore
    keytool -certreq -alias mydomain -keystore <myKeyStore>.jks -storepass <myKeyStorePassword> -file mydomain.csr
  10. generate a Java keystore and key pair
    keytool -genkey -alias mydomain -keyalg RSA -keystore <myKeyStore>.jks -storepass <myKeyStorePassword>
  11. generate a keystore and self-signed certificate
    keytool -genkey -keyalg RSA -alias selfsigned -keystore <myKeyStore>.jks -storepass <myKeyStorePassword> -validity 360
  12. import der certificate into JKS
    keytool -importcert -keystore <keystoreFile> -alias <my.server.alias> -file <my.server.certificate.der>
  13. list certificates


    keytool -list -keystore <myKeyStore>.jks -storepass <myKeyStorePassword>

    Verbose list

    keytool -list -v -keystore <myKeyStore>.jks -storepass <myKeyStorePassword>

6.6 PEM - Privacy Enhanced Email (base64)

  • See pem file.
  • Base64 encoded der file.
  • The name is from Privacy Enhanced Email.
  • It can have a variety of extensions (pem, key, cert, cer, crt, more).
  • Defined in RFC's 1421 through 1424.
  • It's used preferentially by open-source software.

6.6.1 content markers

6.6.2 can contain

Any of the following:

While several certificates, and even the private key, can be included in one file, one below the other, still most platforms, such as Apache, expect the certificates and private key to be in separate files.

6.7 PKCS - Public Key Cryptography Standards

ITEM can contain
*** PKCS #5 - 2.0 - Password-based Encryption Standard private key
*** PKCS #6 - 1.5 - Extended-Certificate Syntax Standard extended certificates
*** PKCS #7 - 1.5 Cryptographic Message Syntax Standard digitally signed messages, certificate
*** PKCS #8 - 1.2 - Private-Key Information Syntax Standard private key
*** PKCS #10 - 1.7 - Certification Request Standard certificate signing request
*** PKCS #12 - 1.1 - Personal Information Exchange Syntax Standard private key, public key, certificate, intermediary certificate

6.7.1 PKCS #1 - 2.2 RSA Cryptography Standard

See RFC 3447. Defines the mathematical properties and format of RSA public and private keys (ASN.1-encoded in clear-text), and the basic algorithms and encoding/padding schemes for performing RSA encryption, decryption, and producing and verifying signatures.

6.7.2 PKCS #2 - Withdrawn

No longer active as of 2010. Covered RSA encryption of message digests; subsequently merged into PKCS #1.

6.7.3 PKCS #3 - 1.4 - Diffie–Hellman Key Agreement Standard

A cryptographic protocol that allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel.

6.7.4 PKCS #4 - Withdrawn

No longer active as of 2010. Covered RSA key syntax; subsequently merged into PKCS #1.

6.7.5 PKCS #5 - 2.0 - Password-based Encryption Standard

  1. algorithms
    1. included in the original PKCS#5 v1.5 specification
      • They only offer 56 bits of protection since they both use DES.
      • PBE-MD2-DES
      • PBE-MD5-DES
    2. PKCS#5 v2.0

      +They use either 64 bit RC2 or 56 bit DES.

      • PBE-SHA1-RC2-64
      • PBE-MD2-RC2-64
      • PBE-MD5-RC2-64
      • PBE-SHA1-DES
  2. example files
    1. PEM PKCS#5 plain private key example
      -----BEGIN RSA PRIVATE KEY-----
      ... (snip) ...
      -----END RSA PRIVATE KEY-----
    2. PEM PKCS#5 encrypted private key example
      -----BEGIN RSA PRIVATE KEY-----
      Proc-Type: 4,ENCRYPTED
      DEK-Info: DES-EDE3-CBC,E83B4019057F55E9
      ... (snip) ...
      -----END RSA PRIVATE KEY-----
  3. operations on file
    1. PEM PKCS#5 private key -> PEM PKCS#8 encrypted private key
      openssl pkcs8 -in p5plain.pem -topk8 -v2 -des3 -out p8enc.pem -passout pass:passwd
    2. read DER PKCS#5 private key
      openssl pkcs8 -in pkcs5.der -inform DER -topk8 -nocrypt

      Terminal output will contain PEM PKCS#8 private key (converted from PKCS#5).

    3. read PEM PKCS#5 private key
      openssl pkcs8 -in pkcs5.pem -topk8 -nocrypt

      Terminal output will contain PEM PKCS#8 private key (converted from PKCS#5).

    4. generate new PEM PKCS#5 plain private key
      • in this example key strength is 2048 bit
      openssl genrsa -out private_key.pem 2048

6.7.6 PKCS #6 - 1.5 - Extended-Certificate Syntax Standard

Defines extensions to the old v1 X.509 certificate specification. Obsoleted by v3 of the same.

6.7.7 PKCS #7 - 1.5 Cryptographic Message Syntax Standard

  • See RFC 2315.
  • Used to sign and/or encrypt messages under a PKI.
  • Used also for certificate dissemination (for instance as a response to a PKCS#10 message).
  • Formed the basis for S/MIME, which is as of 2010 based on RFC 5652, an updated Cryptographic Message Syntax Standard (CMS). Often used for single sign-on.

An open standard used by Java and supported by Windows and Apache Tomcat.

  • Does not contain private key material.
  • Usually stored in Base64 ASCII format
    • contain
      • "–—BEGIN PKCS7–—" and
      • "–—END PKCS7–—" statements.
  • Defined in RFC 2315.
  • format used by windows for certificate interchange.
  • Java understands these natively.
  • Unlike .pem style certificates, this format has a defined way to include certification-path certificates.
  1. operations on file
    1. Convert P7B to pem
      openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer
    2. Convert P7B to pfx
      openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer
      openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CACert.cer
    3. read unencrypted DER PKCS#7 private key:
      openssl pkcs7 -inform DER -in pkcs5.pem

6.7.8 PKCS #8 - 1.2 - Private-Key Information Syntax Standard

  • See RFC 5958.
  • Designed as the Private-Key Information Syntax Standard. It defines what should be included in a private key file.
  • Used to carry private certificate keypairs (encrypted or unencrypted).
  • Has two versions: non-encrypted and encrypted.
  1. example files
    1. PEM PKCS#8 plain private key example
      -----BEGIN PRIVATE KEY-----
      ... (snip) ...
      -----END PRIVATE KEY-----
    2. PEM PKCS#8 encrypted private key example
      ... (snip) ...
  2. operations on the file
    1. Read DER PKCS#8 unencrypted private key:
      openssl pkcs8 -inform DER -nocrypt -in key.der

      Output should look like:

      -----BEGIN PRIVATE KEY-----

6.7.9 PKCS #9 - 2.0 - Selected Attribute Types

  • See RFC 2985.

Defines selected attribute types for use in

  • PKCS #6 extended certificates
  • PKCS #7 digitally signed messages
  • PKCS #8 private-key information
  • PKCS #10 certificate-signing requests.

6.7.10 PKCS #10 - 1.7 - Certification Request Standard

Format of messages sent to a certification authority to request certification of a public key.

See certificate signing request.

  1. example PKCS#10 Certificate Request in PEM format
    ... (snip) ...
  2. operations on a file
    1. inspect CSR file
      openssl req -in <certificateFile> -noout -text

      Sample output

      Certificate Request:
              Version: 0 (0x0)
              Subject: emailAddress=info@mycompany.ee, C=EE, ST=Harjumaa, L=Tallinn, O=My Company AS, OU=Finants, CN=www.mycompany.ee
              Subject Public Key Info:
                  Public Key Algorithm: rsaEncryption
                      Public-Key: (2048 bit)
                      Exponent: 65537 (0x10001)
          Signature Algorithm: md5WithRSAEncryption
    2. create CSR
      private_key.pem existing private key
      csr.pem target CSR file to be generated
      openssl req -sha1 -new -key private_key.pem -out csr.pem

      Example answers:

      question answer comment
      Country Name EE  
      State or Province Name (full name) Harju maakond  
      Locality Name (eg, city) Tallinn  
      Organization Name (eg, company) Minu Firma AS  
      Organizational Unit Name (eg, section) accounting  
      Common Name (e.g. server FQDN or YOUR name) example.com  
      Email Address info@example.com certificate contact email

6.7.11 PKCS #11 - 2.30 - Cryptographic Token Interface

Also known as "Cryptoki". An API defining a generic interface to cryptographic tokens (see also Hardware Security Module). Often used in single sign-on, public-key cryptography and disk encryption systems. RSA Security has turned over further development of11 the PKCS#11 standard to the OASIS PKCS 11 Technical Committee.

6.7.12 PKCS #12 - 1.1 - Personal Information Exchange Syntax Standard

  • Binary format.
  • See RFC 7292.
  • pfx is a predecessor to PKCS #12.
  • Designed as the Personal Information Exchange Syntax Standard. It defines how to package a private key and its certificates into a single file.
  • Can contain multiple embedded objects, such as:
  • Usually encrypted with a password-based symmetric key.
  • Usable as:
    • A format for the Java key store.
    • To establish client authentication certificates in Mozilla Firefox.
    • Usable by Apache Tomcat.
  1. operations on file
    1. extract certificate in PEM format
      openssl pkcs12 -clcerts -in my.p12 -nokeys -out my.crt
    2. extract private key to PEM formatted PKCS #5 encrypted private key file
      openssl pkcs12 -nocerts -in my.p12 -out my.key

6.7.13 PKCS #13 - Elliptic Curve Cryptography Standard

Apparently abandoned, only reference is a proposal from 1998.

6.7.14 PKCS #14 - Pseudo-random Number Generation

Apparently abandoned, no documents exist.

6.7.15 PKCS #15 - 1.1 - Cryptographic Token Information Format Standard

Defines a standard allowing users of cryptographic tokens to identify themselves to applications, independent of the application's Cryptoki implementation (PKCS #11) or other API. RSA has relinquished IC-card-related parts of this standard to ISO/IEC 7816-15.

6.8 XKMS - XML Key Management Specification

W3C standard



6.9 X.509 certificate

6.9.1 operations on the file

  1. convert from PEM to DER
    openssl x509 -in cert.pem -out cert.der -outform DER
  2. convert from DER to PEM
    openssl x509 -inform der -in certificate.cer -out certificate.pem

7 methods

7.1 cryptographic linking / hash chain

every log record is dependent on the previous. This can be accomplished by creating a hash chain making every log record dependent on all others. This prevents from threats of deleting or interjecting falsified log records.

7.1.1 periodical publication of latest log record in printed media.

This mechanism provides for a kind of non-repudiation property for the service provider – it takes away all possibilities to forge the log after publishing as the published log record represents the whole log. Of course, it is usable only when cryptographic linking is used.

7.2 digital signing

Signing a message, means authentifying that you have yourself assured the authenticity of the message (most of the time it means you are the author, but not neccesarily). The message can be a text message, or someone else's certificate.

Advantage of signing your messages is that you transmit your public key and certificate automatically to all your recipients.

7.2.1 to sign a message

  • you create its hash
  • and then encrypt the hash with your private key,
  • you then add the encrypted hash and your signed certificate with the message.

7.2.2 the recipient will

  • recreate the message hash,
  • decrypts the encrypted hash using your well known public key stored in your signed certificate,
  • check that both hash are equals
  • and finally check the certificate.

7.2.3 there are usually 2 ways to sign

  • encapsulating the text message inside the signature (with delimiters)
    • The advantage is that the message is human readable allowing any non complaint client to pass the message as is for the user to read.
  • encoding the message altogether with the signature.
    • This is a very simple encryption form as any software can decrypt it if it can read the embedded public key.
    • does not even allow to read part of the message if it has been tampered with.

7.3 hash

Is a number given by a hash function from a message.

This is a one way function, it means that it is impossible to get the original message knowing the hash.

However the hash will drastically change even for the slightest modification in the message.

It is therefore extremely difficult to modify a message while keeping its original hash.

It is also called a message digest.

Hash functions are used in

  • password mechanisms,
  • in certifying that applications are original (MD5 sum), and in
  • general in ensuring that any message has not been tampered with.

It seems that the Internet Enginering Task Force (IETF) prefers SHA1 over MD5 for a number of technical reasons (Cf RFC2459 7.1.2 and 7.1.3).

8 networking

8.1 HTTPS - Hyper Text Transfer Protocol over Secure sockets layer

8.1.1 retrieve remote HTTPS server certificate

openssl s_client -connect <targetHost>:443 > cert

8.1.2 test HTTPS connection


openssl s_client -showcerts -connect <host>/<pathOnHost>:443 -CAfile /path/to/ssl/certificate.pem

8.2 SSL - Secure Sockets Layer

  • OpenSSL trusted certificates repository located in:

8.2.1 SSL handshake overview

  • Agree on the version of the SSL protocol to use.
  • Select cryptographic algorithms, which are described in CipherSuites and CipherSpecs.
  • Authenticate each other by exchanging and validating digital certificates. For more information, refer to Digital certificates.
  • Use asymmetric encryption techniques to generate a shared secret key, which avoids the key distribution problem. SSL subsequently uses the shared key for the symmetric encryption of messages, which is faster than asymmetric encryption.
  1. the steps involved in the SSL handshake are as follows
    1. The SSL client sends a "client hello" message

      That lists:

      • cryptographic information such as the SSL version and,
      • in the client's order of preference, the CipherSuites supported by the client.
      • The message also contains a random byte string that is used in subsequent computations.

      The SSL protocol allows for the "client hello" to include the data compression methods supported by the client, but current SSL implementations do not usually include this provision.

    2. The SSL server responds with a "server hello" message

      That contains:

      • the CipherSuite chosen by the server from the list provided by the SSL client,
      • the session ID and
      • another random byte string.
      • The SSL server also sends its digital certificate.
      • If the server requires a digital certificate for client authentication, the server sends a "client certificate request" that includes:
    3. The SSL client verifies the digital signature

      on the SSL server's digital certificate and checks that the CipherSuite chosen by the server is acceptable.

    4. The SSL client sends the random byte string

      that enables both the client and the server to compute the secret key to be used for encrypting subsequent message data. The random byte string itself is encrypted with the server's public key.

    5. If the SSL server sent a "client certificate request"
      • the SSL client sends a random byte string encrypted with the client's private key,
      • together with the client's digital certificate, or a "no digital certificate alert". This alert is only a warning, but with some implementations the handshake fails if client authentication is mandatory.
    6. The SSL server verifies the signature on the client certificate.
    7. The SSL client sends the SSL server a "finished" message

      which is encrypted with the secret key, indicating that the client part of the handshake is complete.

    8. The SSL server sends the SSL client a "finished" message

      which is encrypted with the secret key, indicating that the server part of the handshake is complete.

    9. For the duration of the SSL session

      the SSL server and SSL client can now exchange messages that are symmetrically encrypted with the shared secret key.

9 organizations

9.1 ANSI - standards organization

Standards are published in the sense that anyone can buy copies of the standards, but the costs are high enough to interfere with public evaluation. As NIST cryptographer John Kelsey put it in 2014: "public review for ANSI standards was not very public"

9.2 ISO - standards organization

Standards are published in the sense that anyone can buy copies of the standards, but the costs are high enough to interfere with public evaluation.

9.3 NIST - standards organisation

9.5 OASIS PKCS 11 Technical Committee

Responsible for development of PKCS #11 - 2.30 - Cryptographic Token Interface standard.

9.6 RSA Security LLC

10 protocols, standards, infrastructure, models, entities, processes

10.1 CA - certificate authority

Is an entity that issues digital certificates. A trusted third party that is trusted by both the subject (owner) of the certificate and the party relying upon the certificate.


  • issue digital certificates
  • revoke digital certificates
  • manage digital certificates

10.2 certificate

A certificate is insecure until it is signed, as only a signed certificate cannot be modified. You can sign a certificate using itself, it is called a self signed certificate.

All root CA certificates are self signed.

10.2.1 certificate contains

  • the owner of the certificate
    • like e-mail address
    • owner's name
  • the public key
  • certificate usage
    • duration of validity
    • resource location or Distinguished Name (DN)
      • which includes the Common Name (CN)
        • (web site address or e-mail address depending of the usage)
  • certificate ID of the person who certifies (signs) this information.
  • a hash
    • to ensure that the certificate has not been tampered with.

10.2.2 example certificate

        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root CA/Email=administrator@sopac.org
            Not Before: Nov 20 05:47:44 2001 GMT
            Not After : Nov 20 05:47:44 2002 GMT
        Subject: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=www.sopac.org/Email=administrator@sopac.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                Exponent: 65537 (0x10001)
         X509v3 extensions:
             X509v3 Basic Constraints:
             Netscape Comment:
                 OpenSSL Generated Certificate
             X509v3 Subject Key Identifier:
             X509v3 Authority Key Identifier:
                 DirName:/C=FJ/ST=Fiji/L=Suva/O=SOPAC/OU=ICT/CN=SOPAC Root CA/Email=administrator@sopac.org
    Signature Algorithm: md5WithRSAEncryption

As You may have noticed, the certificate contains the reference to the

  • issuer,
  • the public key of the owner of this certificate,
  • the dates of validity of this certificate
  • and the signature of the certificate to ensure this certificate hasen't been tampered with.

The certificate does not contain the private key as it should never be transmitted in any form whatsoever. This certificate has all the elements to:

  • send an encrypted message to the owner (using the public key)
  • verify a message signed by the author of this certificate.

10.3 CRL - Certificate Revocation List

Certificate Authorities produce these as a way to de-authorize certificates before expiration.

10.4 Java applet

10.4.1 securing applet using certificate

  1. get valid certificate
    1. order new certificate
      1. create CSR request

        Generate private key

        keytool -genkey -alias codesigningcert -keyalg RSA -keysize 2048 -keystore <MyKeyStore>.jks

        Generate CSR using private key

        keytool -certreq -alias codesigningcert -file codesigningcert.csr -keystore <MyKeyStore>.jks
      2. import certificates
        1. import certificate authority ROOT certificate
          keytool -import -v -trustcacerts -alias root -file <root>.crt -keystore <MyKeyStore>.jks
        2. import intermediate certificate
          keytool -import -v -trustcacerts -alias intermediate -file <intermediate>.cer -keystore <MyKeyStore>.jks
        3. import bought certificate
          keytool -import -trustcacerts -alias codesigningcert -file <myBoughtCertificate>.cer -keystore <MyKeyStore>.jks
    2. update existing certificate

      If you already have old but expiring certificate. You can reuse existing private key and update certificate instead.

      1. renew certificate from certificate authority

        First generate CSR using existing keystore and private key.

        keytool -certreq -alias codesigningcert -file codesigningcert.csr -keystore <MyKeyStore>.jks

        Submit resulting CSR file as part of certificate renewal application.

        Proceed to the following steps whet you receive new certificate file.

      2. delete old intermediate cert
        keytool -delete -alias intermediate -keystore <MyKeyStore>.jks -storepass <myKeyStorePassword>

        Java key tool does not to override intermediary certificates. We have to delete old one first.

      3. import new intermediary certificate

        We cannot update private key before before valid intermediary certificate is installed. Otherwise java keytool fails to establish certificate chain.

        keytool -import -trustcacerts -alias intermediate -file intermediate.pem.cer -keystore <MyKeyStore>.jks -storepass <myKeyStorePassword>
      4. Overwrite code signing certificate

        As opposed to intermediary certificate updates where you have to explicitly delete the old certificate and insert new one, java keytool actually can update primary certificate itself (when it has private key attached to it).

        Following command replaces old certificate with the new one, while preserving private key related to certificates. (Old and new certificates must be based on the same private key!)

        keytool -import -trustcacerts -alias codesigningcert -file <myBoughtCertificate>.pem.cer -keystore <MyKeyStore>.jks -storepass <myKeyStorePassword>
  2. sign applet
    1. from command line

      Sign JAR file.

      jarsigner -keystore <myKeyStore>.jks -tsa http://timestamp.globalsign.com/scripts/timestamp.dll <myApplet>.jar "myCertInKeystore"
    2. using maven
  3. verify signature
    jarsigner -verbose -certs -verify <MyJarFile.jar>

10.5 JWK - JSON Web Key

A JSON object that represents a cryptographic key. The members of the object represent properties of the key, including its value.

10.5.1 properties

alg the algorithm for the key
kty the key type
use how the key was meant to be used. "sig" represents signature.
x5c the x509 certificate chain
e the exponent for a standard pem
n the modulus for a standard pem
kid the unique identifier for the key
x5t the thumbprint of the x.509 cert (SHA-1 thumbprint)

10.6 JWKS - JSON Web Key Set

A JSON object that represents a set of JWKs. The JSON object MUST have a keys member, which is an array of JWKs.

At the most basic level, the JWKS is a set of keys containing the public keys that should be used to verify any JWT issued by the authorization server.

10.6.1 example

"keys": [
    "alg": "RS256",
    "kty": "RSA",
    "use": "sig",
    "x5c": [
    "n": "yeNlzlub94YgerT030codqEztjfU_S6X4DbDA_iVKkjAWtYfPHDzz_sPCT1Axz6isZdf3lHpq_gYX4Sz-cbe4rjmigxUxr-FgKHQy3HeCdK6hNq9ASQvMK9LBOpXDNn7mei6RZWom4wo3CMvvsY1w8tjtfLb-yQwJPltHxShZq5-ihC9irpLI9xEBTgG12q5lGIFPhTl_7inA1PFK97LuSLnTJzW0bj096v_TMDg7pOWm_zHtF53qbVsI0e3v5nmdKXdFf9BjIARRfVrbxVxiZHjU6zL6jY5QJdh1QCmENoejj_ytspMmGW7yMRxzUqgxcAqOBpVm0b-_mW3HoBdjQ",
    "e": "AQAB",

10.7 JWT - JSON Web Tokens

10.8 OCSP - Online Certificate Status Protocol

An Internet protocol used for obtaining the revocation status of an X.509 digital certificate.

It was created as an alternative to CRL - Certificate Revocation List.

10.9 OSI - Open Systems Interconnection

One of the most complex systems today, and one that also involves a great deal of abstraction, is Open Systems Interconnection (OSI, described in X.200). OSI is an internationally standardized architecture that governs the interconnection of computers from the physical layer up to the user application layer. Objects at higher layers are abstracts built with things from the lower layers.

10.10 PKI - Public Key Infrastructure

software management system and database system that allows to sign certifcate, keep a list of revoked certificates, distribute public key,…

You can usually access it via a website and/or ldap server. There will be also some people checking that you are who you are…

For securing individual applications, you can use any well known commercial PKI as their root CA certificate is most likely to be inside your browser/application.

The problem is for securing e-mail, either you get a generic type certificate for your e-mail or you must pay about USD100 a year per certificate/e-mail address. There is also no way to find someone's public key if you have never received a prior e-mail with his certificate (including his public key).

10.11 PMI - Privilege Management Infrastructure

10.12 private-key

10.12.1 Example keys in various forms

It is pretty easy to see if an SSH key has been encrypted. Simply look for the Proc-Type: 4,ENCRYPTED in the body.

  1. RSA with password

    Proc-Type: 4,ENCRYPTED
    DEK-Info: AES-128-CBC,AF51A101888567A12C6E384AFBD2B963


  2. RSA without password


  3. DSA with password

    Proc-Type: 4,ENCRYPTED
    DEK-Info: AES-128-CBC,2B9F1E1503F57CCC663397AB03CBF3F9


  4. DSA without password


  5. ECDSA with password

    Proc-Type: 4,ENCRYPTED
    DEK-Info: AES-128-CBC,5A3BB12B9B9E17A9A569001A0498969D


  6. ECDSA without password


10.13 public-key

The encryption using a private key/public key pair ensures that the data can be encrypted by one key but can only be decrypted by the other key pair. The keys are similar in nature and can be used alternatively: what one key encrypts, the other key pair can decrypt. The key pair is based on prime numbers and their length in terms of bits ensures the difficulty of being able to decrypt the message without the key pairs. The trick in a key pair is to keep one key secret (the private key) and to distribute the other key (the public key) to everybody. Anybody can send you an encrypted message, that only you will be able to decrypt. You are the only one to have the other key pair, right? In the opposite , you can certify that a message is only coming from you, because you have encrypted it with you private key, and only the associated public key will decrypt it correctly. Beware, in this case the message is not secured you have only signed it. Everybody has the public key, remember!

One of the problem left is to know the public key of your correspondent. Usually you will ask him to send you a non confidential signed message that will contains his publick key as well as a certificate.

Message-->[Public Key]-->Encrypted Message-->[Private Key]-->Message

10.14 symmetric key

Well, Private Key/Public Key encryption algorithms are great, but they are not usually practical. It is asymmetric because you need the other key pair to decrypt. You can't use the same key to encrypt and decrypt. An algorithm using the same key to decrypt and encrypt is deemed to have a symmetric key. A symmetric algorithm is much faster in doing its job than an asymmetric algorithm. But a symmetric key is potentially highly insecure. If the enemy gets hold of the key then you have no more secret information. You must therefore transmit the key to the other party without the enemy getting its hands on it. As you know, nothing is secure on the Internet. The solution is to encapsulate the symmetric key inside a message encrypted with an asymmetric algorithm. You have never transmitted your private key to anybody, then the message encrypted with the public key is secure (relatively secure, nothing is certain except death and taxes). The symmetric key is also chosen randomly, so that if the symmetric secret key is discovered then the next transaction will be totally different.

Symetric Key-->[Public Key]-->Encrypted Symetric Key-->[Private Key]-->Symetric Key

10.15 TSL - Trust Service Status Lists

Is a list of "Trusted List of supervised/accredited Certification Service Providers".

Provides information about the supervision/accreditation status of certification services from Certification Service Providers (CSPs) who are supervised/accredited by particular country for compliance with the relevant provisions of Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures.

Trusted list aims at facilitating the validation of electronic signatures supported by those listed supervised/accredited certification services from the listed CSPs.

10.16 X.509

ITU-T standard for a:

X.509 specifies, amongst other things:

  • standard formats for public key certificates,
  • certificate revocation lists,
  • attribute certificates,
  • certification path validation algorithm.

11 utilities and services

11.1 GPG - GNU Privacy Guard

OpenPGP encryption and signing tool.

11.1.1 Encrypt file

Interactively ask for password

gpg -c <inputfile>

Batch mode

cat myFile.txt | gpg -c --passphrase mySecretPassword --batch > myFile.txt.gpg

11.1.2 Decrypt file

gpg -d <encrypted file> > <decrypted>

11.2 Kerberos

A secure, single sign on, trusted third party mutual authentication service.

As Kerberos is only dealing with Authentication, it does neither Authorization (the step of granting or denying access to a service based on the user wishing to use it), nor Accounting (account and session management, as well as logging)

11.2.1 components

KDC - Key distribution center

11.2.2 known implementations

Kerberos, being a protocol, has many implementations, developed for different purposes:

  1. MIT Kerberos

    The original one; comes from the Project Athena in early 90s. Due to exportation restrictions on cryptography technology, another implementation of Kerberos was developped, in Sweden: Heimdal.

  2. Heimdal Kerberos

    Is MIT Kerberos Swedish counterpart. Heimdal is not restricted by exportation rules. Originally developed in Sweden, it aims to be fully compatible with MIT Kerberos. Since MIT export restrictions were lifted in 2000, both implementations tends to coexist on a wider scale.

    Heimdal stores the server's configuration directly into the database, not in a separated text file like MIT does.

  3. Active Directory

    Not a Kerberos implementation by itself, but kind of. Its the Microsoft's directory, that consist of a loose Kerberos implementation with some other services (LDAP).

    It's not directly compatible with MIT and Heimdal.

  4. TrustBroker

    A commercial implementation of Kerberos protocol, developped by CyberSafe. Supports a wide range of Operating Systems (Windows, Unix, Linux, …), and offers full interoperability with many existing Kerberos implementations, from MIT to Microsoft's AD.

  5. Shishi

    A GNU implementation of Kerberos 5.

11.2.3 versions

There are two publicly available versions for Kerberos, namely v4 (deprecated) and v5 (often written Kerberos 5). While v4 is still used in some places, it is strongly advised to migrate it to a Kerberos 5 implementation, as v5 offers many more functionalities compared to v4, and an improved security.

11.3 PGP - Pretty Good Privacy

Data encryption and decryption computer program that provides cryptographic privacy and authentication for data communication. PGP is often used for signing, encrypting, and decrypting texts, e-mails, files, directories, and whole disk partitions and to increase the security of e-mail communications.

11.5 Letsencrypt

11.5.1 install on Debian 8


  1. Enable the Jessie backports repo, if you have not already done so.
  2. Install certificate management bot
    sudo apt-get install python-certbot-apache -t jessie-backports
  3. Set up automatic certificate update

11.5.2 certificate renewal


sudo certbot renew --dry-run


sudo certbot renew

11.5.3 obtain certificate for new domain

Obtains certificate for main domain and aliases:

sudo certbot certonly -d restcountries.eu -d www.restcountries.eu

11.5.4 automatic certificate update

A practical way to ensure your certificates won’t get outdated is to create a cron job that will periodically execute the automatic renewal command for you. Since the renewal first checks for the expiration date and only executes the renewal if the certificate is less than 30 days away from expiration, it is safe to create a cron job that runs every week or even every day, for instance.

Let's edit the crontab to create a new job that will run the renewal command every week. To edit the crontab for the root user, run:

sudo crontab -e

Include the following content, all in one line:

30 2 * * 1 /usr/local/sbin/certbot-auto renew >> /var/log/le-renew.log

Save and exit. This will create a new cron job that will execute the certbot-auto renew command every Monday at 2:30 am. The output produced by the command will be piped to a log file located at /var/log/le-renewal.log.