Po prihlaseni by to mozno aj chcelo fungovat, akurat javove aplety hadzu
tolko chyb (firefox aj chrome v oboch operacnych systemoch), ze sa to
realne pouzivat neda. Ak o tom nieco vies, testoval to vobec niekto?
@rrickardt:
To, či to niekto testoval fakt netuším (otázka skôr na NCZI). Podľa toho ako sa to správa, tak skôr nie ako áno…
Prihlasovanie s eID podľa všetkého funguje, problém je dešifrovanie údajov cez ECSClient (ActiveX aj Java Applet).
Skúšal som to na W7:
IE11 a s nainštalovaným ECSClient ActiveX:
Rozbehlo sa to až po pridaní “https://ezko.npz.sk” medzi Trusted Sites (cez Internet Options-> Security) a nastavení “Download unsigned ActiveX controls” na “Enable”
Mozilla FF 45.0 a Java Applet:
Zatuhne pri zobrazení Security warning:
Chrome som ani neskúšal (mám verziu 49, ktorá nepodporuje NPAPI)
Inak postaviť to (de)šifrovanie údajov na dožívajúcich technológiách (ActiveX, Java applet) - to chce nejakú “špeciálnu odmenu”, minimálne kopanec…
Nový MS browser (MS Edge) už nepodporuje ActiveX.
Google Chrome už nepodporuje technológiu NPAPI (ktorú využívajú applety) od septembra 2015.
Mozilla plánuje podporu NPAPI vo FF len do konca roka 2016.
Predpokladam, ze vzhladom na to ako sa ten projekt vlecie sa tie technologie dohodli este velmi davno a implementacia hibernuje uz ktovie ako dlho, mozno aj par rokov.
Otazka je, ake su v sucasnosti alternativy pre sifrovanie/desifrovanie cez prehliadac (pouzitelne z javascriptu) s eID kartickou.
Mozno by to chcelo nasledne apelovat na NCZI nech zmenia implementaciu ECSClienta cez alternativne technologie aby sa rozsirila mnozina realne podporovanych prehliadacov. Neviem ci ECSClient je komponent UPVS kedze suvisi s pouzitim eID ako krypto tokenu alebo je to eHealth specific komponent.
Po “odladeni” sa cez IE11 prihlasim do prazdnej zdravotnej knizky (ako uz bolo spomenute, papierova dokumentacia sa zatial scanovat nechysta). Trochu malo aj na potemkina i ked podarilo sa mi pridat “ICE - nudzovy kontakt” a recept mi moze z lekarne vybrat aj sused.
Mozno hlupa otazka ale preco Turk TI? Predpokladam ze to bude iba front end ale aj tak je to pomerne originalne.
Tracing route to ezko.npz.sk [164.40.170.133]
over a maximum of 30 hops:
…
3 3 ms 3 ms 3 ms rw.ba.netlab.sk [84.245.64.249]
4 3 ms 3 ms 4 ms 217.75.72.40
5 21 ms 3 ms 3 ms TurkTI-gw.six.sk [192.108.148.250]
6 5 ms 6 ms 3 ms 31.210.9.154
7 4 ms 3 ms 3 ms 164.40.170.6
8 20 ms 4 ms 3 ms 164.40.170.133
Celkom by ma zaujimala ta uvaha, ako dospeli k tomu dodatocnemu sifrovaniu. Ze su data na serveri sifrovane je super. Ale zjavne sa daju desifrovat aj inym klucom ako eID (ked maju mat pristup ini ludia). Tym padom nevidim pridanu hodnotu v posielani zasifrovanych dat po zasifrovanom kanali… (?)
V princípe sú tie problémy s webovou stránkou minoritné, pretože eHealth funguje predovšetkým ako API rozhranie pre informačné systémy lekárov, nemocníc, ambulancií a lekární. Myslím, že riešenie je veľmi uzavreté a napojené firmy (Lynx, Ness) pracujú zrejme za veľmi výhodných podmienok (pre dané firmy) a nie sú schopné urobiť ani poriadneho klienta a ani poriadne dokončiť celú eHealth server side aplikáciu (napríklad nie je možné momentálne posielať binárne data - roentgeny a pod. - do eHealthu).
Navyše neexistuje otvorené API s popisom a testovacím serverom, kde by si nezávislé firmy mohli vyvíjať svoje softvéry. Musíte ísť do NCZI, žiadať o API, o prístupy atď. a nemáte vlastne isté, že Vás do eHealthu vôbec pustia. Keby existovalo otvorené API, tak by mohol EZK naprogramovať každý.
Keď už mám nainštalovanú aplikáciu pre eID (eID klient), tak by som očakával, že šifrovanie/dešifrovanie na eID sa bude robiť cez ňu. Prihlasovanie s eID funguje na dostupných prehliadačoch, tak by mohlo aj šifrovanie. Určite nie som za to, aby sa pre každú parciálnu funkcionalitu musel inštalovať nejaký nový komponent.
Pozeral som cez fiddler ako funguje to prihlasovanie pomocou eID.
eID klient spusta nieco ako lokalny maly server, v ktorom hostuje sluzbu cez, ktory prehliadac aktivuje okno eID klienta pre overenie pritomnosti karticky a zadavanie BOK kodu.
Je tam normalne z UPVS presmerovanie na “http://localhost:15480” … pokial to zlyha, tak vypise stranku, ze si obcan spustit aplikaciu eID klient.
Inak to tym volanim http://localhost:15480 s par parametrami zjavne sposobi to, ze ta eID klient služba otvorí to okno pre zadávanie BOK kódu. Potom to tam robí ďalej nejaké volania na UPVS.
Prehliadač čaká na odpoveď tej požiadavky, ktorá mu vráti redirect na UPVS url pre pokračovanie v prihlasovaní.
Ak by sa to malo dať využiť na šifrovanie/dešifrovanie, musel by sa tam ešte vytvoriť nejaký šifrovaný kanál medzi prehliadačom a tou HTTP službou eID klienta. Teda to v prípade, že údaje čo sa dešifrujú by nemali opustiť prehliadač a nemali by sa dať ani z lokálnej komunikácie (browser - eID klient) odchytiť.
Zvykne sa to riešiť tak, že na čipovej karte sa dešifruje iba symetrický session kľúč, ktorým sú zašifrované posielané údaje. Takto získaný kľúč sa potom použije na dešifrovanie zašifrovaných údajov. Je to aj kvôli výkonnosti, pretože dešifrovanie veľkého množstva údajov na čipovej karte by trvalo oveľa dlhší čas ako mimo nej. V takomto prípade by dešifrované údaje neopustili prehliadač, cez http (browser - eID klient) by sa posielal iba session kľúč. Šifrované údaje sú zo servera posielané cez https, takže aj z pohľadu bezpečnosti by to takto mohlo byť OK.
„Veríme, že nový spôsob prihlasovania do eHealth sa zvolí na základe poctivej analýzy nákladov a prínosov viacerých alternatív. Jednou z nich by malo byť využitie existujúcich občianskych preukazov," konštatuje Ján Hargaš z platformy Slovensko.Digital.
@janhargas:
O akých alternatívach sa vlastne uvažuje, keď sa spomínajú viaceré? Tú analýzu nákladov a prínosov aj niekto reálne pripravuje alebo veríme, že áno?
Treba pozriet Luborov zapis zo stretnutia v NCZI. Minimalne eID, resp. eID Light. A tiez je tu otazka alternativnych sposobov autentifikacie, ktore vsak musia mat jasne bezpecnostne hranice (QR kod a pod). Jednoducho cela ta debata, ktoru tu vedieme od decembra by sa mala premietnut do vyhodnotenia alternativ vratane ich nakladov a prinosov. A potom by malo padnut rozhodnutie, ako sa teda bude prihlasovat do eHealth.
MZ a NCZI pripravuju novu koncepciu zavedenia eHealth. Ak tato koncepcia bude riesit aj autentifikaciu, tak prave poctiva analyza alternativ prihlasovania je to, co od zaciatku pozadujeme. Predosla studia taka urcite nebola.
inak čisto praktická otázka - načo dieťa potrebuje preukaz keď nie je spôsobila na pravne ukona a nie je anji osoba spôsobila udeliť informovaný súhlas. autentifikovať dieťa môžu rodičia svojim preukazom a nie je problem…
Možno aby mal rodič lepší pocit, že má ďalšiu kartu.
Inak bavím sa pri predstave, ako napríklad moji rodičia budú používať elektronický občiansky preukaz napr. U lekára. Dnes im totiž pomáham aj pri jednoduchých platbách cez internetbanking. Otec ani len nepoužíva bankovú kartu. Architekti egovu by si mohli uvedomiť, že starí ľudia, ktorí sú majoritne klientami nemocníc nemajú vzťah k technológiam. Dokonca starobou prichádzame aj o IT zručnosti alebo o zručnost viest motorové vozidlo. Spomínam si na starú matku, ktorá už v istom štádiu nevedela použiť tlačidlový telefón pre seniorov. Baví ma to cyklické a binárne videnie sveta.
JJ, existuje na to dokonca aj terminus technicus “digital exclusion”
The main challenge of the electronic health record development is of technical and organisational nature: The cost for building up the necessary IT infrastructure (centralised) and the equipment, which is needed by healthcare providers, are implementation barriers. Further concerns are related to the legislative situation in Slovakia at that time. The centralisation of a huge amount of sensitive data causes a great deal of discussion, whether this collection of individual data is necessary and where the limits for collection will be set. People, who oppose the creation of such data sets, are concerned with the danger of data theft and accidental disclosure of private information. Some portion of the ICT professionals doubt that such project will be accepted by the population. Another problem is that there has been no broader discussion about the security of the solution. The presented concepts focused on the central data storage, while the individual computers used to access/create content of the central storage are omitted. Potentially number of such computers could be in the 10.000’s range. Recently NBU the National security authority responsible for protecting of classified information has been hacked by teenage hackers after they discovered trivial passwords. The present setting of the data collection scope includes any and all health related data which is a major concern that this is far more than necessary data collection. This may be even in the violation of one’s constitutional right to privacy. Further aggravating circumstance is the fact that there is currently no opt-in model for the creation of an electronic healthcare record. Another issue in debate is the possible “digital exclusion” of certain groups, e.g. disabled, low-educated, elder people and marginal social groups.
Pán pacient, spomeňte si na svoj BPIN inak Vám nemôžem poskytnúť zdravotnú starostlivosť, ak mi to tu elektronicky nepodpíšete.
Pán doktor, ja mám niekedy pocit, že zabúdam, že som taký blby.
Pán pacient, aký je dnes deň?
Neviem.
Koľko je hodín?
Hm. - Pacient znervóznie, lebo nevie označiť presný čas.
Ako sa vola váš syn?
Jozef ( Jozef je v skutočnosti mladší súrodenec, ktorý už 20 rokov nežije) syn sa vola Peter.
Chápem že IT obchodnici sú platení od počtu certifikátov, záznamov v produkcii, a rozumiem že potrebuju zarobiť, ale reálny život je ďaleko pestrejší a zložitejší. Preto egov služby treba cieliť iba na tých, ktorí ich reálne využijú.