All posts by Bozho

I Have Been Appointed As E-Governance Minister of Bulgaria

Post Syndicated from Bozho original https://techblog.bozho.net/i-have-been-appointed-as-e-governance-minister-of-bulgaria/

Last week the Bulgarian National assembly appointed the new government. I am one of the appointed ministers – a minister for electronic governance.

The portfolio includes digitizing registers and processes in all government institutions, reducing bureaucracy, electronic identity, cybersecurity, digital skills and more.

Thanks to all my readers for following this blog throughout the years. I will be sharing some digital policy details here from now on while I’m minister. That may include some technical articles, but they are unlikely to be developer-oriented.

I hope to make some important changes and put forward key ideas for e-governance and digital policy that can be used as an example outside my country (last time I was involved in public policy, I helped pass an “open source law”).

I’ve written a few articles about IT people looking for challenges – not just technical challenges. And I think that’s a great challenge where I’ll have to put all my knowledge and skills to work for the common good.

The post I Have Been Appointed As E-Governance Minister of Bulgaria appeared first on Bozho's tech blog.

Министър на електронното управление

Post Syndicated from Bozho original https://blog.bozho.net/blog/3890

В понеделник ще бъда предложен на Народното събрание за министър на електронното управление.

Отговорността и очакванията са огромни, а задачите – неизброими.

Ще започнем с електронната идентификация, с отпадането на удостоверения и с оптимизираме и електронизиране на ключови процеси. Ще трябва паралелно с това да създадем и министерство.

Целта е да премахнем бюрокрацията и да спестим време и нерви на гражданите и бизнеса.

Благодаря на всички за продължаващата подкрепа.

Материалът Министър на електронното управление е публикуван за пръв път на БЛОГодаря.

Simple Things That Are Actually Hard: User Authentication

Post Syndicated from Bozho original https://techblog.bozho.net/simple-things-that-are-actually-hard-user-authentication/

You build a system. User authentication is the component that is always there, regardless of the functionality of the system. And by now it should be simple to implement it – just “drag” some ready-to-use authentication module, or configure it with some basic options (e.g. Spring Security), and you’re done.

Well, no. It’s the most obvious thing and yet it’s extremely complicated to get right. It’s not just login form -> check username/password -> set cookie. It has a lot of other things to think about:

  • Cookie security – how to make it so that a cookie doesn’t leak or can’t be forged. Should you even have a cookie, or use some stateless approach like JWT, use SameSite lax or strict?
  • Bind cookie to IP and logout user if IP changes?
  • Password requirements – minimum length, special characters? UI to help with selecting a password?
  • Storing passwords in the database – bcrypt, scrypt, PBKDF2, SHA with multiple iterations?
  • Allow storing in the browser? Generally “yes”, but some applications deliberately hash it before sending it, so that it can’t be stored automatically
  • Email vs username – do you need a username at all? Should change of email be allowed?
  • Rate-limiting authentication attempts – how many failed logins should block the account, for how long, should admins get notifications or at least logs for locked accounts? Is the limit per IP, per account, a combination of those?
  • Captcha – do you need captcha at all, which one, and after how many attempts? Is Re-Captcha an option?
  • Password reset – password reset token database table or expiring links with HMAC? Rate-limit password reset?
  • SSO – should your service should support LDAP/ActiveDirectory authentication (probably yes), should it support SAML 2.0 or OpenID Connect, and if yes, which ones? Or all of them? Should it ONLY support SSO, rather than internal authentication?
  • 2FA – TOTP or other? Implement the whole 2FA flow, including enable/disable and use or backup codes; add option to not ask for 2FA for a particular device for a period of time>
  • Login by link – should the option to send a one-time login link be email be supported?
  • XSS protection – make sure no XSS vulnerabilities exist especially on the login page (but not only, as XSS can steal cookies)
  • Dedicated authentication log – keep a history of all logins, with time, IP, user agent
  • Force logout – is the ability to logout a logged-in device needed, how to implement it, e.g. with stateless tokens it’s not trivial.
  • Keeping a mobile device logged in – what should be stored client-side? (certainly not the password)
  • Working behind proxy – if the client IP matters (it does), make sure the X-Forwarded-For header is parsed
  • Capture login timezone for user and store it in the session to adjust times in the UI?
  • TLS Mutual authentication – if we need to support hardware token authentication with private key, we should enable TLS mutual. What should be in the truststore, does the web server support per-page mutual TLS or should we use a subdomain?

And that’s for the most obvious feature that every application has. No wonder it has been implemented incorrectly many, many times. The IT world is complex and nothing is simple. Sending email isn’t simple, authentication isn’t simple, logging isn’t simple. Working with strings and dates isn’t simple, sanitizing input and output isn’t simple.

We have done a poor job in building the frameworks and tools to help us with all those things. We can’t really ignore them, we have to think about them actively and take conscious, informed decisions.

The post Simple Things That Are Actually Hard: User Authentication appeared first on Bozho's tech blog.

Integrity Guarantees of Blockchains In Case of Single Owner Or Colluding Owners

Post Syndicated from Bozho original https://techblog.bozho.net/integrity-guarantees-of-blockchains-in-case-of-single-owner-or-colluding-owners/

The title may sound as a paper title, rather than a blogpost, because it was originally an idea for such, but I’m unlikely to find the time to put a proper paper about it, so here it is – a blogpost.

Blockchain has been touted as the ultimate integrity guarantee – if you “have blockchain”, nobody can tamper with your data. Of course, reality is more complicated, and even in the most distributed of ledgers, there are known attacks. But most organizations that are experimenting with blockchain, rely on a private network, sometimes having themselves as the sole owner of the infrastructure, and sometimes sharing it with just a few partners.

The point of having the technology in the first place is to guarantee that once collected, data cannot be tampered with. So let’s review how that works in practice.

First, we have two define two terms – “tamper-resistant” (sometimes referred to as tamper-free) and “tamper-evident”. “Tamper-resistant” means nobody can ever tamper with the data and the state of the data structure is always guaranteed to be without any modifications. “Tamper-evident”, on the other hand, means that a data structure can be validated for integrity violations, and it will be known that there have been modifications (alterations, deletions or back-dating of entries). Therefore, with tamper-evident structures you can prove that the data is intact, but if it’s not intact, you can’t know the original state. It’s still a very important property, as the ability to prove that data is not tampered with is crucial for compliance and legal aspects.

Blockchain is usually built ontop of several main cryptographic primitives: cryptographic hashes, hash chains, Merkle trees, cryptographic timestamps and digital signatures. They all play a role in the integrity guarantees, but the most important ones are the Merkle tree (with all of its variations, like a Patricia Merkle tree) and the hash chain. The original bitcoin paper describes a blockchain to be a hash chain, based on the roots of multiple Merkle trees (which form a single block). Some blockchains rely on a single, ever-growing merkle tree, but let’s not get into particular implementation details.

In all cases, blockchains are considered tamper-resistant because their significantly distributed in a way that enough number of members have a copy of the data. If some node modifies that data, e.g. 5 blocks in the past, it has to prove to everyone else that this is the correct merkle root for that block. You have to have more than 50% of the network capacity in order to do that (and it’s more complicated than just having them), but it’s still possible. In a way, tamper resistance = tamper evidence + distributed data.

But many of the practical applications of blockchain rely on private networks, serving one or several entities. They are often based on proof of authority, which means whoever has access to a set of private keys, controls what the network agree on. So let’s review the two cases:

  • Multiple owners – in case of multiple node owners, several of them can collude to rewrite the chain. The collusion can be based on mutual business interest (e.g. in a supply chain, several members may team up against the producer to report distorted data), or can be based on security compromise (e.g. multiple members are hacked by the same group). In that case, the remaining node owners can have a backup of the original data, but finding out whether the rest were malicious or the changes were legitimate part of the business logic would require a complicated investigation.
  • Single owner – a single owner can have a nice Merkle tree or hash chain, but an admin with access to the underlying data store can regenerate the whole chain and it will look legitimate, while in reality it will be tampered with. Splitting access between multiple admins is one approach (or giving them access to separate nodes, none of whom has access to a majority), but they often drink beer together and collusion is again possible. But more importantly – you can’t prove to a 3rd party that your own employees haven’t colluded under orders from management in order to cover some tracks to present a better picture to a regulator.

In the case of a single owner, you don’t even have a tamper-evident structure – the chain can be fully rewritten and nobody will understand that. In case of multiple owners, it depends on the implementation. There will be a record of the modification at the non-colluding party, but proving which side “cheated” would be next to impossible. Tamper-evidence is only partially achieved, because you can’t prove whose data was modified and whose data hasn’t (you only know that one of the copies has tampered data).

In order to achieve tamper-evident structure with both scenarios is to use anchoring. Checkpoints of the data need to be anchored externally, so that there is a clear record of what has been the state of the chain at different points in time. Before blockchain, the recommended approach was to print it in newspapers (e.g. as an ad) and because it has a large enough circulation, nobody can collect all newspapers and modify the published checkpoint hash. This published hash would be either a root of the Merkle tree, or the latest hash in a hash chain. An ever-growing Merkle tree would allow consistency and inclusion proofs to be validated.

When we have electronic distribution of data, we can use public blockchains to regularly anchor our internal ones, in order to achieve proper tamper-evident data. We, at LogSentinel, for example, do exactly that – we allow publishing the latest Merkle root and the latest hash chain to Ethereum. Then even if those with access to the underlying datastore manage to modify and regenerate the entire chain/tree, there will be no match with the publicly advertised values.

How to store data on publish blockchains is a separate topic. In case of Ethereum, you can put any payload within a transaction, so you can put that hash in low-value transactions between two own addresses (or self-transactions). You can use smart-contracts as well, but that’s not necessary. For Bitcoin, you can use OP_RETURN. Other implementations may have different approaches to storing data within transactions.

If we want to achieve tamper-resistance, we just need to have several copies of the data, all subject to tamper-evidence guarantees. Just as in a public network. But what a public network gives is is a layer, which we can trust with providing us with the necessary piece for achieving local tamper evidence. Of course, going to hardware, it’s easier to have write-only storage (WORM, write once, ready many). The problem with it, is that it’s expensive and that you can’t reuse it. It’s not so much applicable to use-cases that require short-lived data that requires tamper-resistance.

So in summary, in order to have proper integrity guarantees and the ability to prove that the data in a single-owner or multi-owner private blockchains hasn’t been tampered with, we have to send publicly the latest hash of whatever structure we are using (chain or tree). If not, we are only complicating our lives by integrating a complex piece of technology without getting the real benefit it can bring – proving the integrity of our data.

The post Integrity Guarantees of Blockchains In Case of Single Owner Or Colluding Owners appeared first on Bozho's tech blog.

Представителна история за една шофьорска книжка

Post Syndicated from Bozho original https://blog.bozho.net/blog/3887

Миналата година на мой близък човек му изтече шофьорската книжка. И решихме да пробваме да бъде заявена новата онлайн. Тогава още я нямаше обновената система на МВР за е-услуги, така че свалихме бланката, попълнихме я и я изпратихме през системата за сигурно електронно връчване, подписана с КЕП, вкл. с прикачено необходимото медицинско.

Влизането с КЕП също не беше тривиално, защото инсталирането на софтуера за подписване имаше някои неочевидни настройки.

Последва дежурното обаждане (от пътна полиция към СДВР) „то не може“, предадено към мен – настоях за правно основание за отказа, тъй като Законът за електронно управление ги задължава да приемат заявлението и да изпълнят услугата. Казаха, че пак ще звъннат. Не звъннаха. Потърсихме ги отново, като в отговор потвърдиха, че не – няма да издадат така книжката.

Подадохме сигнал до Държавна агенция „Електронно управление“, аргументирайки се, че мълчаливият (към онзи момент) отказ противоречи на Закона за електронното управление.

Отговорът на ДАЕУ беше да се съгласят мотивите от изричния отказ на МВР, получен няколко дни след това. А той е абсурден. Според Закона за българските лични документи, МВР предоставя електронни услуги за лични документи през централизирана система за услуги. В правилния за прилагане на закона се изреждат услугите, включени в портала. Но издаване на шофьорска книжка липсва (тъй като към онзи момент не се поддържа). Да, Законът за електронното управление казва следното:

(2) Административните органи, лицата, осъществяващи публични функции, и организациите, предоставящи обществени услуги, са длъжни да предоставят всички услуги в рамките на своята компетентност и по електронен път, освен ако закон предвижда особена форма за извършване на отделни действия или издаване на съответни актове.

Обаче МВР казва „нашият подзаконов акт дерогира (отменя) закона, защото нашият специален закон делегира детайлите на нашия подзаконов акт, а той не казва нищо за тая конкретна услуга“. Абсурдна теза, граничеща с тази на РИК Стара Загора при отказа за вписване на листата на Демократична България, но останал несанкциониран.

Е, месец-два след това се появиха електронните услуги в системата, така че този казус вече не съществува. Но той илюстрира три проблема, за чието решаване ще работя:

  • Неудобно е – след като се оправиш с неудобния и „чуплив“ квалифициран електронен подпис, трябва да търсиш бланки (които ги няма там, където трябва – в административния регистър)
  • „Не може по електронен път“ – администрацията си търси всякакви абсурдни оправдания за да „им дойдеш“ на гише, както са си свиканли
  • Няма контрол – ДАЕУ като че ли беше уплашено, че няма политическата подкрепа да напише акт на МВР и да им издаде задължително предписание да спазват закона, макар че има такива правомощия

Само първият от тези проблеми е технически. Останалите са организационни и политически. И ще трябва да бъдат решени.

Материалът Представителна история за една шофьорска книжка е публикуван за пръв път на БЛОГодаря.

Избран съм за народен представител

Post Syndicated from Bozho original https://blog.bozho.net/blog/3884

ЦИК обяви резултатите. Избран съм за народен представител.

Благодаря на всички за подкрепата. За мен лично, за Демократична България и за посоката на промяна.

Няма да спестя клишето, че тя е задължаваща. И че гледам на депутатството не като „награда“, а като на отговорност.

Ще работя за модернизация на държавата. И за това всички затлачвани дейности и замитани проблеми да бъдат поправени.

Не самоцелно, а за да не бъде държавата в тежест на гражданите и бизнеса, да не пилее парите ни с неефективността си.

Ще приемам предложения, ще приемам и критики. Ще опитвам да обяснявам решенията си и политиките, които прокарвам. Ще опитам да бъда „представител“ в истинския смисъл.

И ще се постарая да имаме перспективно, прозрачно и добро управление, което да бъде в ярък контраст с предишните.

Още веднъж – благодаря.

Материалът Избран съм за народен представител е публикуван за пръв път на БЛОГодаря.

Кратък следизборен анализ

Post Syndicated from Bozho original https://blog.bozho.net/blog/3881

Благодаря на всички, гласували за Демократична България и за мен лично.

Да, Демократична България реализира значителен спад в получените гласове. И със сигурност е имало какво да направим по-добре и по-правилно. Но нека обясня причините за това, както ги виждам през многото данни, които минаха през ръцете ми.

ГЕРБ, БСП и ДПС са „изпилени“ до ядрата си – с малки изключения никой не може да вземе глас от тях и те не могат да вземат глас от никого. Остават другите, които искат промяна. Техните гласове два пъти отидоха за ДБ, ИТН и ИБНИ, но поради хаотичните и неадекватни действия на ИТН, това не доведе до резултат. Негативът от това се понесе и от трите партии.

В началото на кампанията ДБ загуби част от избирателите си в посока Продължаваме промяната, най-вече по линията „Радев“. След това започна бавно да си ги „връща“, докато не дойде необяснимата атака на подкрепения от ДБ кандидат за президент. Това, според мен, счупи най-важното – усещането за стабилност и предвидимост в ДБ. Не че самата стабилност и предвидимост ги няма, но тези необясними действия в този електорален терен казаха на част от избирателите „тука има нещо особено, можете да ходите другаде“. Според екзит половете в крайна сметка над 1/3 от гласовете на ДБ през юли са отишли към ПП. Това далеч не е единственият фактор, разбира се. И тези избиратели не принадлежат на никого.

Факторът „новост“ комбиниран с умората от 3-ти поредни избори на останалите партии, комбиниран с неуспеха в предния парламент, комбиниран с одобрението на Радев, комбиниран с добрата им кампания донесе този успех на Продължаваме промяната, които „изсмукаха“ трудно спечелените избиратели от ДБ през тази година.

Можеше ли нещо друго да се направи? Нито можехме да бъдем нов субект след 2 кампании, нито след 2 кампании можехме да сменим рязко посланията, нито имаше откъде да привлечем други избиратели – тези на ГЕРБ, БСП и ДПС са „заключени“, а както беше казал някой – негласуващите имат една характерна особеност – не гласуват.

Нямаше как и да подкрепим Радев – дори само агентите на ДС в инициативния му комитет правят такъв избор почти невъзможен. Дори в момента 50% от избирателите ни гласуваха за Радев. Ако не се бе появила ПП, щяха да са 2/3 (такива бяха данните). И когато Лозан Панов атакува остро Радев (макар и не без причини, както посочих преди малко), допълнително „отпъди“ хора, които биха ни подкрепили, но пък харесват Радев. Получих доста такива коментари в кампанията. Бяхме наясно и с това явление, но поне 1/3 от избирателите ни щяха да са тежко разочаровани от липсата на кандидат. Панов очевидно беше напълно независим, което може би беше тактическа грешка, но много хора от ядрото ни оценяват тази независимост.

Друго важно решение, което взехме – да бъдем партньорски и позитивно настроени спрямо ПП, също имаше, макар и по-малък негативен електорален ефект – много от хората ни считат за естествен партньор след изборите и особено в изборния ден вероятно са взели решение „нека едните наши да бият ГЕРБ, после ще управляват с другите наши“. Споделените ни периферии в областните центрове потвърждават това. В други исторически моменти дясното се е нахвърляло върху всичко ново. И е губило много от това в дългосрочен план.

И последно – нашите ясни послания „за“ ваксинация нямаше как да ни донесат допълнителна подкрепа при тези ниски нива на доверие във ваксините. Но когато умират толкова, това беше отговорната, принципна позиция.

Важните решения, които взехме, на база принципи, бяха с ясен и предвидим електорален резултат – негативен. Първо, че не подкрепихме кабинета на ИТН и отказахме преговори с мандат на БСП беше част от причините за трети избори. Само че просто няма как да дадем такава подкрепа и да се погледнем в огледалото. Изборът да не подкрепим Радев, въпреки, че мнозинството от избирателите ни го подкрепяха, също беше базиран на принципи, макар да носи гарантирани електорални щети.

Цялата тази комбинация от фактори допринесе за по-слабия резултат, а не толкова кампанията ни – тя беше правена от същите хора, които доведоха коалицията от съмнения за влизане до 12% през юли. И, иронично или не, резултатът е следствие от принципните ни решения и на много сложната обстановка. Но в политиката е така.

Представляването на избиратели с разнородни и понякога противопололожни мнения е трудно. Задържането им мотивирани в три поредни кампании, последната от които, съвпадаща с президентската, при поява на нов субект на същия електорален терен, е почти невъзможно. Аз все пак заставам зад всички взети решения – те са такива, защото ние сме такива. Това носи електорални рискове, но носи и увереност, че правим правилните неща за България. И че ще ги правим, когато имаме възможност да управляваме.

Нека не забравяме, че преди година този резултат би бил определян като „успех“. Сега не е, защото екипът ни показа, че може да постига резултати.

И да, Продължаваме промяната преразпределиха гласовете на партиите извън БСП, ДПС и ГЕРБ. Привлякоха малко негласуващи за сметка на 2-та процента „фира“ от ИБНИ. Но смятам, че те са много по-перспективен и позитивен водещ партньор от ИТН и съответно резултатите на тези избори са по-скоро позитивни. Предстоят коалиционни преговори и се надявам скоро да имаме добри новини и ще можем да реализираме идеите, които печелиха доверие.

Материалът Кратък следизборен анализ е публикуван за пръв път на БЛОГодаря.

Рискове и мерки за защита на машинното гласуване

Post Syndicated from Bozho original https://blog.bozho.net/blog/3868

Тези дни ескалираха съмненията в машинното гласуване. Тази ескалация е с политически мотив, но няма да правя политически коментар, а експертен, с който да обясня къде всъщност са рисковете за машинното гласуване и какви са мерките, които трябва да вземем, за да бъде то защитено. Ще опитам да обясня и защо допълнителни машини по никакъв начин не помагат за компрометирането на системата, ако Сиела биха искали да я компрометират.

Тук е важно да отбележа, че не твърдя, че някой иска да манипулира резултата – нито Сиела, нито ЦИК, нито Информационно обслужване. Но една добра система трябва да бъде отворена и прозрачна и да може всяка заинтересована страна да се убеди, че тя работи правилно, без да разчита на някой доверен участник. Т.е. дори да вярваме на Сиела, ЦИК и Информационно обслужване, сме длъжни да имаме система, която не разчита на доверието към тях.

Машинното гласуване не е просто една машина, то е процес. Процесът има следните стъпките:

  1. Доставка на празни машини
  2. Получаване на изходния код
  3. Компилиране на изходния код до системен образ
  4. Електронно подписване на системния образ
  5. Записване на подписания системния образ на флашка
  6. Инсталиране на системния образ на всички машини (отключване на машините, в случай, че на тях е бил инсталиран друг системен образ, подписан с други ключ)
  7. Генериране на ключове върху смарт-карти (тези белите, с които секционните комисии подписват)
  8. Комплектоване на смарт-картите и техните ПИН-кодове
  9. Транспортиране на машините и смарт-картите до РИК, съответно до секциите
  10. Стартиране на изборния ден
  11. Гласуване
  12. Приключване на изборния ден и подписване на протокола (както на хартия, така и електронно)
  13. Транспортиране на хартиения протокол, смарт-картите и флаш-паметите с машинния протокол
  14. Проверка на протокола и въвеждането му в системата за машинна обработка
  15. Сумиране и обявяване на резултата

На почти всяка от тези стъпки съществува някакъв риск, който трябва да бъде адресиран. Рискът може да бъде за манипулация на целия изборен процес или на отделни секции. Рискът не значи, че това ще се случи, но трябва да бъдат взети съответните мерки. Сходни рискове съществуват и при хартиеното гласуване – и там има защитни механизми (като напр. голям брой членове на секционни комисии, наблюдатели, бюлетини с уникален номер, и т.н.)

Нека започна с въвеждането на колко термина, които ще ми се наложи да използвам в обяснението.

  • Криптографски ключ – освен като ключ, с който може да се отключва и заключва електронно съдържание, може да си го представите като много дълга (незапомняема) парола, която ни дава достъп до дадена скрита информация, но също така ни дава опция да “подпишем” нещо електронно.
  • Електронен подпис – използване на криптографски ключ с цел гарантиране, че даден файл не е бил подменян и че е създаден от оторизирано за това лице (притежател на ключа)
  • Хеш – “отпечатък” на файл или група от файлове. Хешът е това, което се разпечатва на разписката и служи за идентифициране на софтуера, който работи на машината. Всяка най-малка промяна в дори един файл би променила този хеш.
  • Изходен код – кодът описва как работи софтуера – какво прави в един или друг случай, как смята, къде записва резултата
  • UEFI secure boot – това е технология, която ограничава възможния системен софтуер, който може да работи на една машина само до такъв, който е бил електронно подписан с ключ на оторизиран участник (между другото, всеки домашен компютър или лаптоп също използва тази технология).

В целия процес има три групи рискове, които надграждат един върху друг. Основният риск е първият, защото той определя поведението на системата, но останалите рискове са свързани с него:

  • Изходният код – съществува риск някой (доставчикът) да е заложил определено изкривяване на резултата в изходния код, напр. “всеки трети глас за Х отива за Y или Z”.
  • Системният образ – дори кодът да бъде проверен и да не манипулира резултата, системният образ, който е изграден на база на този код, може да бъде подменен с друг. Затова трябва да сме сигурни, че системният образ е точно този, който е изграден от проверения изходен код
  • Управление на ключове – гарантирането на системния образ, а и на машинните протоколи на флаш-паметите, разчита на електронни подписи с криптографски ключове. Те трябва да бъдат управлявани и съхранявани правилно, за да не може някой да подмени едно или друго съдържание.

Следва таблица с рисковете по тези направления, както и мерки, които са взети за тяхното елиминиране. Ще си позволя да добавя колона “участие на ДБ”, защото всякакви обвинения в манипулация са абсолютно нелепи при всичките усилия, които системно полагаме за честността на изборите. Държа да подчертая, че знанието, описано тук, сме го използвали, за да подобрим процеса.

А откъде имам информация за този анализ? От общи познания по информационна сигурност, от техническата спецификация за поръчката, от докладите за удостоверяване на машините на Държавна агенция “Електронно управление” и от участието ми на техническите срещи с експерти от ДАЕУ и ЦИК, на които задавах въпроси. Не твърдя, че имам пълната картина, но имам достатъчно, така че да оценя рисковете.

Броенето на хартиените разписки е мярка, която позволява откриването на манипулации, ако бъде изпълнена както трябва. Затова и още при предните избори настоявахме чрез нашите представители в ЦИК за извадкова проверка. При проверката на разписките гаранцията идва от това, че избирател се е уверил визуално, че машината е приела гласа, който той е подал. Затова е добра идея да има извадково преброяване в СИК (напр. в 5% от секциите), както и по-обстоен централизиран следизборен одит на разписките, при който рисковете от грешки и от умишлен саботаж са намалени. Важно е при одита да бъде сканиран и QR кода, защото той е гаранцията, че разписката е автентична, а СИК трябва да документира всички извънредни събития, като граждани, тръгнали си с разписка в джоба, свършила хартия и др., които могат да се отразят на броя разписки. Този подход би открил опит за мащабна манипулация, без да създава предпоставки за друг вид манипулации – комуникационни, в които определени технически грешки при броенето и въвеждането на резултата се използват за подкопаване на доверието в изборите.

Риск Мерки за защита Прилагат ли се в момента? Ниво на риск Участие на ДБ
Уязвимости в кода, които позволяват промяна на резултата Автоматизирано тестване за уязвимости на изходния код; Да, от ДАЕУ в процеса на удостоверяване Ниско (това за уязвимости, които не са съзнателно поставени и съответно, дори да ги има, не е ясно дали някой може да се възползва от тях) Не директно, но процеса на удостоверяване беше добавен включително и заради натиска на ДБ за одит на машините.
“Вратичка” (backdoor) в кода, която позволява съзнателна манипулация Преглед на кода от участници в процеса и в процеса на удостоверяване Частично – в момента ДАЕУ проверява кода, но все още ЦИК не е дала достъп до представителите на партиите Високо Предложено от ДБ в Изборния кодекс. Три писма, както и внесено проект на решение на ЦИК.
Подмяна на изходния код след неговото одитиране и преди компилиране на системния образ Генериране на хеш на изходния код и публикуването му Да, в рамките на публичната процедура се сравнява хеша на удостоверения код с този на кода, с който се компилира системния образ. Високо В техническата среща настоявах това да се случи; все пак от Сиела и ДАЕУ вече се бяха подготвили с тази стъпка. Публичното компилиране на системния образ беше поискано от ДБ чрез писмо и становище в комисия в Народното събрание
Вкарване на злонамерена функционалност през библиотеки, които не са част от кода, но системата разчита на тях Проверка на електронните подписи или хешовете на библиотеките спрямо публично обявените Частично – това е част от скриптовете за компилиране на системния образ, до които не са ни предоставили достъп. Ниско – такава атака е с висока сложност, защото в кода трябва да има код, който да се възползва от тази промяна по неочевиден начин. –
Инсталиране на системен образ, различен от официалния, който да изкривява резултата Подписване на официалния с ключ на ЦИК; Извадкова проверка на UEFI db на машините в процеса на инсталиране извадкова проверка на хеша с външен инструмент HashExtractor Частично – от тези избори системният образ се подписва от ЦИК, а не от Сиела. На предните избори е извършена проверка на процеса на инсталиране, но тя трябва да е по-мащабна. Очакваме решение на ЦИК за извадкова проверка с HashExtractor Високо. Хешът на системната разписка е само частична гаранция, тъй като той се генерира от машината (и тя може да разпечата “правилния’). Затова е нужно разделяне на контрола на ключа и инсталирането (за да не са в една и съща организация) ДБ в няколко писма за предните и тези избори предлага на ЦИК извадкова проверка с външния инструмент HashExtractor, както и проверка на UEFI db (дали разпознава правилните ключове или са добавени изключения) и е подкрепила подписването с ключ на ЦИК
Управляване на машината дистанционно в изборния ден Неизползване на карта за безжична комуникация и премахване на драйверите за всякакви мрежови карти. Да, машините са с премахнати мрежови драйвери по спецификация (и това е потвърдено при удостоверяването) и нямат антени за безжична комуникация Ниско Изрично сме се уверили на база на докладите, че няма възможност за отдалечена комуникация с машините.
Изтичане на ключа за UEFI secure boot Генериране на ключа на смарт-карта и съхранение в сигурна физическа среда; евентуално разпределение на ключа между членовете на ЦИК с напр. С алгоритъма за споделяне на ключове на Шамир. За съжаление не може ключът да се генерира на смарт-карта, защото ако тя се развали, губим машините. Алтернативно, може да се генерира на HSM, който поддържа резервни копия. Частично – доколкото разбрах ЦИК е приело протоколни правила за генерирането и съхранението на ключовете и се пазят физически. За следващите избори това трябва да стане в публична процедура. Средно – изтичането на ключа не значи автоматично манипулация на изборите. В този случай проверката с HashExtractor отново би открила проблема, а разделението между собственика на ключа и организацията, инсталираща машините, допълнително намалява риска. Още на предните избори в писмо сме поискали точните процедури за управление на UEFI ключовете
Подписване на секционни машинни протоколи с нелегитимни ключове Публикуване на всички сертификати от смарт-картите на секционните комисии преди изборния ден, което да позволи последваща проверка и защита срещу нелегитимни ключове Не, в момента се разчита, че карти могат да се издават само от Информационно обслужване и че няма допълнително издадени карти. Ниско, тъй като хартиеният протокол, от който имат копие всички членове на СИК и наблюдателите, съдържа валидните данни и хващането на такава манипулация е лесно.. С писмо от миналата седмица до ЦИК сме поискали публикуване на всички сертификати/публични ключове
Подписване на фалшив машинен протокол по пътя от СИК до РИК Разделяне на смарт-картите от флаш-паметите при транспорта Не, в момента се разчита, че такава манипулация в мащаб едва ли е възможна, поради необходимостта от технически познания на член на СИК. Ниско, тъй като хартиеният протокол, от който имат копие всички членове на СИК и наблюдателите, съдържа валидните данни и хващането на такава манипулация е лесно. С писмо преди предходните избори сме предложили разделяне на смарт-картите от флаш-паметите
Изкривяване на резултата при машинна обработка в РИК/ЦИК Публикуване на всички протоколи; получаване на копие от протоколите от всеки член на СИК и застпъник Да Много ниско – протоколите са първичният документ и след неговото генериране всеки опит за мащабна манипулация може да бъде установен много лесно. –

Виждаме, че на практика всички рискове са или адресирани по някакъв начин, или с достатъчно ниско ниво, за да не представляват системен проблем. Моята критика, когато има такава, е в подобряване на вече прилаганите мерки за защита.

Ако приемем, че допълнителните машини са за манипулация на изборите, то Сиела е тази, която би го направила. Само че Сиела в момента разполага с UEFI ключа от предните избори, с който може да отключи съществуващите, “легитимни” машини. Именно затова допълнителните машини с нищо не се различават от съществуващите и не добавят вектор на атака. При следващите избори, в които Сиела няма да има ключа да отключи съществуващите машини, това би било потенциален проблем, тъй като в новите машини може да инсталира всичко, а в старите – само системен образ, подписан от ЦИК. Но на тези разлика няма.

Когато говорим за изходния код, за съжаление в момента той не е собственост на държавата и тя няма право да го публикува. Може, в условия на конфиденциалност, да се предостави на заинтересовани страни (представители на партии, напр.) Това трябва да бъде коригирано за следващи избори – добра идея е да се напиша изцяло нов код, който да е публично достъпен, одитиран, и за чийто прелед да бъдат поканени международни експерти. За това тази година нямаше време, но при малко по-стабилен парламент това трябва да бъде следващата стъпка, според мен.

С оглед на изложеното по-горе, смятам, че изборите в момента са с разумно ниво на защита и че мащабни манипулации няма да бъдат извършвани. Има какво да се желае от процеса, поради което правим постоянни препоръки. ЦИК приема някои от тях, макар и със закъснение.

Бих препоръчал за следващите избори ЦИК да позволи на партиите да изпратят свои представители в складовете, където се извършва инсталирането на машини, и да могат, оп определен ред, да задават въпроси и следят процеса.

Знам, че гореописаното е сложно и твърде експертно. И изисква наблюдатели на етапи различни от изборния ден, на места различни от изборната секция. Но категорично не съм съгласен с политическите внушения, че щом е по-сложно, значи някой го манипулира.

До момента машинното гласуване елиминира невалидните гласове и намали купения и контролиран вот (вероятно защото няма “тъмна стаичка” и не може да се снима екрана, не може да се носят конци за отмерване на дължина, не могат да се изнасят бюлетини в нишка и др.); елиминираха се и грешките при броенето в СИК, а процесът на приемане на протоколи се ускори. Това са ползи, които си струват допълнителното усилие. Ако намерим други начини за справяне с тези проблеми, супер. Но дотогава, нека партиите наистина впрегнат симпатизиращите им ИТ експерти да наблюдават процеса и да се уверяват в неговата честност, вместо да рисуват абсурдни конспиративни графики и да всяват несигурност и недоверие.

Материалът Рискове и мерки за защита на машинното гласуване е публикуван за пръв път на БЛОГодаря.

България ще бъде различна

Post Syndicated from Bozho original https://blog.bozho.net/blog/3855

В последната година и половина в България се промениха много неща. Те не са очевидни в ежедневнието, но са значителни и са важно начало. Ще опитам да дам моя „вътрешен“ поглед на ситуацията и по-важното – какво предстои. Смятам, че има четири етапа не тези промени.

До средата на 2020 г. всичко изглеждаше монотонно и предрешено – ГЕРБ щеше да спечели още един мандат, социологията от май месец даваше сравнително високо доверие за Борисов и кабинета, а на хоризонта нямаше алтернатива. Тогава се случи събитие, което „разбърка“ нещата. Росенец.

На Росенец Христо Иванов и съмишленици осветиха преплитането на власт, икономически и лични интереси; осветиха влиянието и безнаказаността на ДПС и демаскираха зависимостите на ГЕРБ. Тогава написах, че Росенец е начало. И макар в момента много хората да опитват да омаловажат това събитие, мисля, че историците след много години ще го анализират и ще му отдадат необходимата важност.

След Росенец последва неизбежния отговор на президента заради подопечната му НСО, в който той атакува ДПС, Доган и Борисов. Последва и контраатака на зависимата от ДПС прокуратура, която влезе в президентството. Двете събития доведоха до протести, които промениха коренно картината и макар да не свалиха Борисов, предвещаха края на управлението му.

Росенец даде началото на първия етап. Вторият етап започна с парламентарните избори през април. До тях много хора все още не вярваха, че ГЕРБ няма да управлява и че няма да бъде отпусната тяхната хватка над властови и икономически влияния. Но изборният резултат и последващата твърдост на „партиите на протеста“ размагьоса избирателите – вече беше ясно, че ерата „Борисов“ свършва. ГЕРБ се сви до едно ядро избиратели, което е много различно от това, което ги държа на власт толкова време. Изборите дадоха начало на отпускането на властовите инструменти от ГЕРБ и ДПС, доведоха до служебно правителство, което разрови доста схеми, за които медии и опозиция говореха отдавна, но те си продължаваха и се разрастваха.

„Партиите на протеста“ станаха „партии на промяната“, но кабинет така и не беше сформиран. Причините са много, но могат да се обобщят с това, че се беше случила важна промяна в политическия пейзаж – вече нямаше един голям, който да определя условията. Това ще бъде трайната политическа ситуация, с която партиите трябва да свикват – ще има 5-6 средни по големина партии, които трябва да се научат на коалиционна култура, за да може да има управление.

Третият етап започва на 14 ноември. След изборите има шанс партиите на промяната да направят коалиционно управление, което да управлява с експертност и приличие; с прозрачност и отговорност; управление, което да реши затлачвани с години проблеми в правосъдие, образование, здравеопазване, инфраструктура, а и на практика всяка сфера. Такова управление не е гарантирано, а заявките, които ГЕРБ, ДПС и БСП дадоха в края на предния парламент за съвместни действия, продължени от действията на техните представители в ЦИК в тази предизборна кампания, са плашеща алтернатива – „още от същото, но дори по-грозно“.

Ако това не се случи и все пак партиите на промяната постигнат достатъчно висок резултат, в средносрочен план предстои четвъртата стъпка – промяна на мисленето. Мисленето, че сме аутсайдери, че нищо не зависи от нас, че е окей да сме последни, че е нормално всичко да е корумпирано. Да спрем да се дърпаме надолу в казана. Да водим, а не да догонваме.

Смятам, че последните година и половина и следващите две-три години са от историческа важност за България. И затова влагам усилията си в политическа кауза, каквато е Да, България и Демократична България. При всички рискове и негативи от това. България ще излезе различна от този период и зависи от всеки едни от нас да е към по-добро.

Материалът България ще бъде различна е публикуван за пръв път на БЛОГодаря.

Защо не трябва да се броят 100% от контролните разписки от машинното гласуване?

Post Syndicated from Bozho original https://blog.bozho.net/blog/3852

Демократична България обжалва решението на ЦИК за 100% преброяване на контролите разписки (по партии/коалиции) и вписването на този резултат в отделни протоколи. Аргументите са изложени в детайли в жалбата, ето „накратко“:

  • ЦИК няма право да дописва така Изборния кодекс. В Изборния кодекс се казва нищо такова, ЦИК си измисля правила. И то същия ЦИК, който преди 2 седмици каза „щом не пише изрично, че може с електронен подпис, значи не може“. Само че разликата в случая с разписките е, че няма общ ред, който да важи.
  • Разписките не са бюлетини – те се броят по-трудно (с по-дребен шрифт са, не се сгъват еднакво, а това допринася за повече грешки. Изначално, идеята за машините е да спестят многото човешки грешки; сега ЦИК иска да ги върне „на стероиди“. Тук има и един друг аспект – бюлетините имат поредни номера и защитни механизми; разписките нямат. Всеки може да фалшифицира разписка и да я пусне заедно със своята. Или вместо своята, ако реши да саботира изборите. Единственият начин да се провери, че една разписка е истинска е чрез QR кода, само че в методическите указания такава проверка липсва, а секционните комисии не са длъжни да имат смартфон с приложение за четене и интерпретиране на тези QR кодове.
  • протоколите от ръчното преброяване не подлежат на проверка с автоматизирани контроли при приемането им в РИК, на каквато подлежат протоколите при броене на хартиени бюлетини. Т.е. нито РИК, нито Информационно обслужване ще проверяват дали не пише пълни глупости в този протокол – просто ще го сканират и ще го качат с грешките.
  • световната практика никога не е да се броят 100% от разписките. Винаги се брои извадка – колко да е тя е отделен въпрос, но е абсолютно безсмислено да се хвърля усилие за 100% с всички рискове, изброени по-горе. Досега винаги (и в България, и на други места, където се гласува с машини), разминаванията с резултата от машината винаги са били заради човешка грешка при броенето.

Освен, че предложението има всички тези проблеми, това, което то се опитва да постигне има доста по-разумни решения. Разписките представляват т.нар. voter-verifiable paper audit trail (VVPAT), или проверима от гласоподавателя хартиена одитна следа. Те могат да бъдат проверявани по няколко начина, така че да гарантират, че машините наистина записват това, което избирателят е искал.

  • извадкова проверка – напр. на 2 или 5 процента от секциите. Ако има компрометирани машини, които дават глаове на една партия, вземайки ги от другите, то при проверка на определен процент секции на случаен принцип, това ще се види. Нужно е да има такова несъответсвие дори само в 1 секция, за да предизвика по-задълбочена проверка. При такова несъответсвие, обаче, трябва да се проверят и QR кодовете на всички разписки. Вместо на случаен принцип, може партиите и коалициите да посочват в кои секции искат да се извърши проверката.
  • броене на общия брой разписки и последващо преброяване на резултатите по партии/коалиции само ако общият брой не излезе.
  • следизборен одит, проведен централизирано, със съответните QR четци.

Мнозинството в ЦИК обаче иска да прехвърли всичко на секционните комисии, които да създадат едни протоколи извън закона, които нямат стойност за изборния резултат, но които могат да бъдат използвани удобно от противниците на машинното гласуване.

Нека ЦИК приеме по-разумни правила за одитиране, така че наистина да има гаранции за работата на машините, а не да създава допълнителен хаос и неясноти. И не на последно място – да позволи експертите от партиите да се включим пълноценно в одита, вкл. с достъп до изходния код.

И нека партиите, чиито представители гласуваха за това решение (ГЕРБ, БСП, ДПС, ИТН) да послушат поне малко експертни аргументи, и особено ГЕРБ да спрат да плашат избирателите с несъществуващи конспирации.

Материалът Защо не трябва да се броят 100% от контролните разписки от машинното гласуване? е публикуван за пръв път на БЛОГодаря.

Трудният разговор за Информационно обслужване

Post Syndicated from Bozho original https://blog.bozho.net/blog/3845

Трудният разговор за Информационно обслужване трябва да започне.

Още в края на 2019 г. остро критикувах решението на ГЕРБ да изтрият цяла глава от Закона за електронно управление (маскирайки неуспеха си да създадат държавно предприятие „Единен системен оператор“) и с едно изречение да прехвърлят цялото ИТ на всяка институция, която Министерският съвет реши, под „крилото“ на Информационно обслужване.

Тази уредба премахва изискванията за прозрачност, позволява схеми с вътрешно възлагане тип „Автомагистрали“, не гарантира предсказуемост (за един ден МС може да извади една институция от списъка и да „убие“ всяко планиране).

Няма да се съглася с разпространеното мнение, че Информационно обслужване е пълно с некадърници, които нищо не могат да свършат. Там има хора, които всяка ИТ компания би искала да има, и които са много над средното ниво. Има, разбира се, и такива, които никоя не би искала. Като във всяка голяма компания.

Но институционално погледнато, ролята на системния интегратор (или оператор) е важна. Държавната администрация няма капацитет за почти нищо в сферата на ИТ и трябва да може да се довери на някого. Дори за да направиш аутсорсинг (=ЗОП), пак трябва да имаш компетентност, каквато в много администрации няма.

Трябва да отчетем един факт – миналата есен Информационно обслужване изгради национална здравна информационна система за няколко седмици, когато това беше нужно. И го направи добре, по мое мнение. След като 4 години тази система се беше бавила по различни причини.
DDoS атаките от последните дни са сериозни и едва ли има компания, която може да се защити без никакъв downtime. Познавам инфраструктурата на ИО в тази ѝ част и мисля, че е направено достатъчно.

Въпросите, на които трябва да отговорим, са няколко:

  • Трябва ли всяка администрация да си поръчва софтуерни лицензи и хардуер самостоятелно? Моят отговор е „не“ – в много държави има успешни примери за централизирано управление на лицензи и стандартизирани поръчки за хардуер, така че държавата да получи възможно най-добрите оферти. В Тексас дори има агенция, за която производителите имат специални отстъпки в ценовите си листи, защото веднъж влязъл в процеса, производителят получава достъп до цялата администрация „на един клик разстояние“. Информационно обслужване може да върши тази работа.
  • Трябва ли всяка администрация да поддържа ИТ компетенции? Отново не; то не е и възможно. Да, трябва да има грамотен ИТ директор, но принципът на „споделените услуги“ изисква вътрешно възлагане на неща като писане на технически задания, текущ контрол по същество (а не по документи), интегриране на системи, спешна извънгаранционна поддръжка и др.
  • Трябва ли ИО да е „черна кутия“? Не – това е критика към сегашната уредба. Нищо в закона не задължава ИО да публикува никой от договорите за вътрешно възлагане. Наложи се да искаме договора и заданието за изграждане на НЗИС по реда на Закона за достъп до обществена информация. от МЗ дори поискаха удължаване на срока, явно е било трудно да го намерят. Трябва изрична уредба за каталог на предоставяните услуги, цени, на които се предоставят и пълна прозрачност на извършеното – какво, за кого, колко, кога.
  • Не е ли по-добре всичко да се аутсорсне към частния сектор? Краткият отговор е „не винаги“, а дългият е тук: https://blog.bozho.net/blog/3254. За съжаление резултатът през годините не винаги е в полза на този подход. Това не значи, че държавната фирма ще се справи по-добре, разбира се.
  • Трябва ли ИО да пише софтуер за администрациите и при какви условия? Това е най-трудният въпрос. Ако ползваме здравната система за пример, отговорът би бил „да“ – след години нищоправене, ИО свърши работата. Но само на този пример не бива да си правим заключения. Вероятно правилният подход е да се уредят няколко критични сектора в закон, така че да има предвидимост, и извън тях ИО да има само поддържаща функция. Това ще е важната част от дебата в следващото Народно събрание.

Все пак Информационно обслужване е важен инструмент за държавата. Има много слабости, които трябва да бъдат коригирани, много конкретика, която да бъде прецизно уредена. Моделът на ГЕРБ „слагаме един ред в закона и правим каквото си искаме“ трябва да спре. Но тези проблеми имат решения и ще ги приложим в следващия управленски мандат.

Материалът Трудният разговор за Информационно обслужване е публикуван за пръв път на БЛОГодаря.

Разяснения по казуса с прилагането на електронен подпис в изборния процес

Post Syndicated from Bozho original https://blog.bozho.net/blog/3841

Ще вляза в може би малко скучната материя за йерархията и връзката между нормативните актове. За да видим защо решението на ЦИК, че квалифицирания електронен подпис не важи за Изборния кодекс е неадекватно.

Да, не съм юрист, но тази базова правна рамка – кой какво задължение има в електронния свят е основата на електронното управление и като експерт по електронно управление съм длъжен да я знам и разбирам.

Нормативните актове имат йерархия. Конституция, Регламент, Закон, Наредба/Правилник/Инструкция. Ако някой акт от по-ниска степен противоречи на някой акт от по-висока, то се прилага този от по-висока. Освен ако този от по-висока не допуска изключения. Законът за нормативните актове дава общата картина:

Чл. 15. (1) Нормативният акт трябва да съответствува на Конституцията и на другите нормативни актове от по-висока степен.
(2) (Нова – ДВ, бр. 46 от 2007 г.) Ако нормативен акт противоречи на регламент на Европейския съюз, прилага се регламентът.
(3) (Предишна ал. 2 – ДВ, бр. 46 от 2007 г.) Ако постановление, правилник, наредба или инструкция противоречат на нормативен акт от по-висока степен, правораздавателните органи прилагат по-високия по степен акт.

Кодексите са малко по-специфични закони. Тяхната идея е да уредят напълно една материя – Изборният кодекс урежда всичко, свързано с избори (за да няма, както преди, закон за изборите за народно събрание, закон за изборите за президент и вицепрезидент и т.н.). Наказателният кодекс урежда всички престъпления и никой друг закон не може да урежда престъпления. И т.н.

Кодексите (както и законите), обаче, не съществуват в изолация. Макар Изборният кодекс да урежда изцяло изборната материя, към него се прилагат нормите от други закони – напр. когато става въпрос за гражданство, Изборният кодекс не урежда въпроса за гражданството – той е уреден в Закона за българското гражданство. Когато става дума за личните документи, с които гласуваме, те не са уредени в кодекса, а в Закона за българските лични документи. Когато става дума за административно производство, процесът е уреден в Административнопроцесуалния кодекс (различията с него са изрично уредени в изборния, който дори изрично препраща към АПК).

Когато става дума за приемане на електронни изявления, за електронни документи и електронни подписи, тогава се прилагат Регламент (ЕС) 910/2014, Закона за електронния документ и електронните удостоверителни услуги и Закона за електронното управление.
Та, изборният кодекс не урежда нищо специфично свързано с подписи и документи – разчита на общия ред (вкл. чл. 18а от АПК). А общият ред е такъв – административните органи са длъжни да приемат електронни изявления. Чл. 5 от ЗЕДЕУУ, чл. 11 от ЗЕУ (и дори чл. 8, ал. 2) и чл. 18а от АПК.

Ако вече не съм ви загубил дотук, има още един въпрос – РИК и ЦИК административни органи ли са и доставчици ли са на административни услуги? Дефиницията на „административна услуга“ е Закона за администрацията е доста широка и включва „извършване на други административни действия, които представляват законен интерес за физическо или юридическо лице;“ (макар че вписването на листа може да попада и в по-конкретните точки, дори). Всъщност, дори да не бяха, чл. 18а от АПК ги задължава да приемат документи по електронен път.
Това, между другото, е пример, как едно и също задължение се урежда на няколко места „за всеки случай“, защото някой административен орган някъде е казвал „аа, не, тоя закон не важи за мен“.

Та, ЦИК и РИК са задължени да приемат електронни изявления и са задължени от Регламента да ги приравни на саморъчен подпис. Дори Изборният кодекс да не урежда това изрично, и дори това да се счита за противоречие, Регламентът „печели“, защото така пише в Закона за нормативните актове (той пък е следствие от един текст в Конституцията за международните договори).

Остава аргументът на ЦИК – „щом на някои места в Изборния кодекс е посочено изрично, че може да се използва квалифициран електронен подпис, значи никъде другаде не може, защото не е посочено изрично“. Това е доста превратно (и несъстоятелно) тълкуване на правна норма изобщо.
Местата, където се позволява изрично използване на електронен подпис, са подписките. Те не са част от административния процес, и не са заявление до административен орган. Затова въпросът е по-сив. Там имаше нужда и да се коригира допускането, че подписът се полага лично ПРЕД упълномощено лице (електронният няма смисъл да се полага така).

Знам, че е много интересно човек да се упражнява по темата „кой кога занесъл флашка“ и „щом ЦИК казва, че не важи, значи не важи“. Но законът в една държава е съвкупност от правни норми, които за удобство са разделени под различни заглавия, но представляват просто серия от взаимодействащи си норми. А склонността на българските органи да признават само своя закон и никой друг закон е много лоша практика, която води до такива казуси. А съдът е този, който трябва да каже „не, вашият закон не съществува в паралелна правна вселена“

Материалът Разяснения по казуса с прилагането на електронен подпис в изборния процес е публикуван за пръв път на БЛОГодаря.

Въпроси и отговори за отказа на РИК и ЦИК да регистрира листата на Демократична България

Post Syndicated from Bozho original https://blog.bozho.net/blog/3834

Тъй като днес се натрупаха доста въпроси по казуса с електронните подписи и листата в Стара Загора, правя компилация от тях и техните отговори:

Въпрос: Внесли ли сте всички документи в електронен вид или само разпечатка на електронния подпис на хартия, както пишеше в някои медии?

Отговор: И РИК на своето заседание, и ЦИК в решението си признават, че всички необходими документи са внесени в електронен вид, в рамките на срока, свалени са от флаш-паметта на компютър на РИК и подписите са проверени. След това РИК в решението си прикриват тези детайли.

Въпрос: Какъв тогава е проблемът, ако всичко е внесено както трябва?

Отговор: Проблемите според РИК и ЦИК са различни. Според РИК липсва „вярно с оригинала“ на хартиена разпечатка на оригиналния документ, без каквато те твърдят, че документите са невалидни (въпреки, че са свалили и проверили оригиналите). Проблемът според ЦИК е, че изобщо не може да се използват електронни подписи, въпреки, че европейският регламент, който приравнява електронния подпис на саморъчен се прилага пряко, а РИК и ЦИК са задължение да приемат електронни документи и да признават квалифицираните електронни подписи без да има предварителна уговорка със заявителя.

Въпрос: Защо твърдите, че има атака от ГЕРБ, при положение, че те отричат, посочвайки, че председателката на РИК 27 е от ИТН?

Отговор: Освен решението за потвърждаване на отказа, ЦИК приема да изпрати на всички районни комисии писмо, с което да събере информация дали има подадени листи с електронен подпис (които биха били в нарушение съгласно мотивите на приетото от ЦИК решение). Предложението за това е на Красимир Ципов от ГЕРБ. Подкрепено, отново, от всички останали (без представителите на ДБ).

Въпрос: Нормално ли е да се внасят листите в последния ден?

Отговор: абсолютно нормално е – на практика всички значими партии го правят в последния ден, защото това дава гъвкавост в особени ситуации. Ако видите решенията на РИК 27, решеняита за регистрация на ДБ, ГЕРБ, БСП, ДПС, ИБНИ и ПП са от 12-ти. Само на ИТН е от 11-ти.

Въпрос: Защо ги подавате с електронен подпис, а не на хартия като всички останали?

Отговор: Този въпрос е принципен – когато твърдим, че дигитализацията е приоритет, е редно да изпозлваме правата си според действащото законодателство. И да ги защитаваме, когато се чуе редовната реплика на администрацията: „Това не може с електронен подпис!“

Въпрос: Това значи ли, че ще останете без листа?

Отговор: Административният съд в Стара Загора ще реши, след като обжалваме пред него.

Материалът Въпроси и отговори за отказа на РИК и ЦИК да регистрира листата на Демократична България е публикуван за пръв път на БЛОГодаря.

Кандидат съм за народен представител в София област

Post Syndicated from Bozho original https://blog.bozho.net/blog/3830

Днес Демократична България внесе кандидатските листи за изборите на 14 ноември. Водач съм на листата в 26 МИР – София област. Част съм и от листата в 23-ти МИР в София, но на по-задно място.

Аз съм експерт по електронно управление и вярвам, че тази тема е особено важна именно за Софийска област. Защо?

За да не трябва да хората да казват “отивам до София да оправя едни документи”, всяко взаимодействие с държавата може и трябва да става от компютъра или телефона ни.

В останалите 27 области на страната голяма част от жителите живеят в областния град и в общия случай не пътуват дълго, когато им се наложи да използват някаква административна услуга от държавата. Докато жителите на Софийска област трябва да заделят повече време и да направят повече разходи, за да си свършат работата с институциите, които се намират в София – областната администрация, териториалната дирекция на НАП, кадастъра, агенцията по вписванията, областната дирекция на МВР… Някои от тях имат изнесени офиси в градовете в областта, но това не винаги е достатъчно, а и не е необходимо.

Електронното управление е важно и по много други причини, които съм коментирал в кампанията през юни.

Водач на ГЕРБ в Софийска област е не кой да е, а Младен Маринов, вътрешният министър на Бойко Борисов, при когото електронната идентификация не помръдна. А тя е ключът към електронното управление.

Няма да пестя сили в работата си и по други важни за областта теми, като здравеопазването, образованието, водата, транспорта, природните богатства и техния потенциал.

Необходимо е да опазваме горите – там съвременните технологии също могат да са много полезни за установяване и спиране на незаконни сечи.

Необходима е и крайградска железница, така че хиляди хора, идващи да работят в София, да имат удобен и уютен транспорт, вместо да висят в задръствания сутрин и вечер.

Необходими са и много други политики, с които животът в страната да стане по-добър и по-достоен. По всички проблеми ще работя в открито сътрудничество с местните общности и с експертите и депутатите на Демократична България.

Но за да може промяната да бъде устойчива и България да ускори модернизацията си, е необходимо първо да не допуснем връщането на ГЕРБ и ДПС във властта – те дълго време я използваха за съвсем други цели. Трябва да реформираме из основи съдебната система и регулаторните органи. Без това няма как да си гарантираме свободата, законността и конкуренцията.

Предизборната кампания ще бъде трудна и поради разрастващата се вълна на епидемията, както и поради есенно-зимното време. Когато срещите с избирателите на живо са невъзможни, ще използвам всички технологични средства за дистанционен разговор.

Материалът Кандидат съм за народен представител в София област е публикуван за пръв път на БЛОГодаря.

В отговор на Борисов относно машинното гласуване

Post Syndicated from Bozho original https://blog.bozho.net/blog/3825

Бойко Борисов ме споменал поименно в свой коментар за машинното гласуване. Както обикновено, фриволно борави с фактите, затова трябва да уточня някои неща. Нашите усилия за подобряване на честността на изборите са последователни и конструктивни и не са от вчера. Борисов казал (във връзка с писмо на Демократична България до ЦИК)

Но сега колегите от „Да, България“ поискаха от ЦИК да извърши нова проверка на машините за гласуване – я виж ти. В писмо до ЦИК експертите посочват, че са необходими още тестове, които да гарантират честността на вота. Те имаха представители досега при кода, само че сега нямат и вече и те дълго изброяват къде са рисковете. И ние настоявахме да има одит на машините. Г-н Божанов, от месеци ви споделяме съмненията си, че правят далавери. Тези 0,8 процента ги броиха 3 дни, за да изкарат Слави първи, не помните ли“

По същество:

  • От Да, България настояваме за независим одит на машините от 2017 г. Настоявахме за него го за изборите през април – тогава мнозинството на ГЕРБ и ДПС игнорира предложенията ни. Искахме го през юли, но тогава имаше валиден аргумент – използването на идентичен софтуер с априлския. Така че опитът му да изкара, че сега сме се сетили, е доста нелеп.
  • “Те имаха представители досега при кода” – представители сме нямали “при кода”. Аз бях представител при удостоверяването, където обсъждахме доста технически аспекти. (Там ГЕРБ не помня да имаха експерт, въпреки всичките им публични изяви по темата. Когато се стигна до “работа, работа, работа”, те си мълчаха.)
  • 0.8 процента не са ги броили три дни – от много години на избори последните под 1% не се въвеждат в сайта на ЦИК, докато не е минала втората проверка на протоколите в ЦИК (първата е в РИК). Тъй като има хартиени протоколи, финалните резултати не се обявяват. Борисов и и хората им в ЦИК знаят това и е демагогия да говорят такива неща.

Напомням също така, че измененията в Изборния кодекс през април, с които се въведе задължителен достъп до изходния код за представителите на партиите и коалициите, беше на Демократична България. ГЕРБ не го подкрепи.

Всъщност, писмото, което изпратихме тази седмица до ЦИК е почти идентично на писмо, което бяхме изпратили за изборите през юли. Опитите ни да подобрим процеса не са от вчера, но нямаме намерение да влизаме в тона на Борисов, че някой манипулира изборите. Не го правихме дори когато мнозинството в ЦИК беше тяхно. Призовавам Борисов и колегите му в ГЕРБ към по-отговорно и последователно поведение спрямо изборния процес и към по-внимателно боравене с фактите. И се надявам да видя техен представител на удостоверяването на машините този път.

Материалът В отговор на Борисов относно машинното гласуване е публикуван за пръв път на БЛОГодаря.

Hypotheses About What Happened to Facebook

Post Syndicated from Bozho original https://techblog.bozho.net/hypotheses-about-what-happened-to-facebook/

Facebook was down. I’d recommend reading Cloudflare’s summary. Then I recommend reading Facebook’s own account on the incident. But let me expand on that. Facebook published announcements and withdrawals for certain BGP prefixes which lead to removing its DNS servers from “the map of the internet” – they told everyone “the part of our network where our DNS servers are doesn’t exist”. That was the result of a backbone self-inflicted failure due to a bug in the auditing tool that checks whether the commands executed aren’t doing harmful things.

Facebook owns a lot of IPs. According to RIPEstat they are part of 399 prefixes (147 of them are IPv4). The DNS servers are located in two of those 399. Facebook uses a.ns.facebook.com, b.ns.facebook.com, c.ns.facebook.com and d.ns.facebook.com, which get queries whenever someone wants to know the IPs of Facebook-owned domains. These four nameservers are served by the same Autonomous System from just two prefixes – 129.134.30.0/23 and 185.89.218.0/23. Of course “4 nameservers” is a logical construct, there are probably many actual servers behind that (using anycast).

I wrote a simple “script” to fetch all the withdrawals and announcements for all Facebook-owned prefixes (from the great API of RIPEstats). Facebook didn’t remove itself from the map entirely. As CloudFlare points out, it was just some prefixes that are affected. It can be just these two, or a few others as well, but it seems that just a handful were affected. If we sort the resulting CSV from the above script by withdrawals, we’ll notice that 129.134.30.0/23 and 185.89.218.0/23 are the pretty high up (alongside 185.89 and 123.134 with a /24, which are all included in the /23). Now that perfectly matches Facebook’s account that their nameservers automatically withdraw themselves if they fail to connect to other parts of the infrastructure. Everything may have also been down, but the logic for withdrawal is present only in the networks that have nameservers in them.

So first, let me make three general observations that are not as obvious and as universal as they may sound, but they are worth discussing:

  • Use longer DNS TTLs if possible – if Facebook had 6 hour TTL on its domains, we may have not figured out that their name servers are down. This is hard to ask for such a complex service that uses DNS for load-balancing and geographical distribution, but it’s worth considering. Also, if they killed their backbone and their entire infrastructure was down anyway, the DNS TTL would not have solved the issue. But
  • We need improved caching logic for DNS. It can’t be just “present or not”; DNS caches may keep “last known good state” in case of SERVFAIL and fallback to that. All of those DNS resolvers that had to ask the authoritative nameserver “where can I find facebook.com” knew where to find facebook.com just a minute ago. Then they got a failure and suddenly they are wondering “oh, where could Facebook be?”. It’s not that simple, of course, but such cache improvement is worth considering. And again, if their entire infrastructure was down, this would not have helped.
  • Consider having an authoritative nameserver outside your main AS. If something bad happens to your AS routes (regardless of the reason), you may still have DNS working. That may have downsides – generally, it will be hard to manage and sync your DNS infrastructure. But at least having a spare set of nameservers and the option to quickly point glue records there is worth considering. It would not have saved Facebook in this case, as again, they claim the entire infrastructure was inaccessible due to a “broken” backbone.
  • Have a 100% test coverage on critical tools, such as the auditing tool that had a bug. 100% test coverage is rarely achievable in any project, but in such critical tools it’s a must.

The main explanation is the accidental outage. This is what Facebook engineers explain in the blogpost and other accounts, and that’s what seems to have happened. However, there are alternative hypotheses floating around, so let me briefly discuss all of the options.

  • Accidental outage due to misconfiguration – a very likely scenario. These things may happen to everyone and Facebook is known for it “break things” mentality, so it’s not unlikely that they just didn’t have the right safeguards in place and that someone ran a buggy update. The scenarios why and how that may have happened are many, and we can’t know from the outside (even after Facebook’s brief description). This remains the primary explanation, following my favorite Hanlon’s razor. A bug in the audit tool is absolutely realistic (btw, I’d love Facebook to publish their internal tools).
  • Cyber attack – It cannot be known by the data we have, but this would be a sophisticated attack that gained access to their BGP administration interface, which I would assume is properly protected. Not impossible, but a 6-hour outage of a social network is not something a sophisticated actor (e.g. a nation state) would invest resources in. We can’t rule it out, as this might be “just a drill” for something bigger to follow. If I were an attacker that wanted to take Facebook down, I’d try to kill their DNS servers, or indeed, “de-route” them. If we didn’t know that Facebook lets its DNS servers cut themselves from the network in case of failures, the fact that so few prefixes were updated might be in indicator of targeted attack, but this seems less and less likely.
  • Deliberate self-sabotage – 1.5 billion records are claimed to be leaked yesterday. At the same time, a Facebook whistleblower is testifying in the US congress. Both of these news are potentially damaging to Facebook reputation and shares. If they wanted to drown the news and the respective share price plunge in a technical story that few people understand but everyone is talking about (and then have their share price rebound, because technical issues happen to everyone), then that’s the way to do it – just as a malicious actor would do, but without all the hassle to gain access from outside – de-route the prefixes for the DNS servers and you have a “perfect” outage. These coincidences have lead people to assume such a plot, but from the observed outage and the explanation given by Facebook on why the DNS prefixes have been automatically withdrawn, this sounds unlikely.

Distinguishing between the three options is actually hard. You can mask a deliberate outage as an accident, a malicious actor can make it look like a deliberate self-sabotage. That’s why there are speculations. To me, however, by all of the data we have in RIPEStat and the various accounts by CloudFlare, Facebook and other experts, it seems that a chain of mistakes (operational and possibly design ones) lead to this.

The post Hypotheses About What Happened to Facebook appeared first on Bozho's tech blog.

Digital Transformation and Technological Utopianism

Post Syndicated from Bozho original https://techblog.bozho.net/digital-transformation-and-technological-utopianism/

Today I read a very interesting article about the prominence of Bulgarian hackers (in the black-hat sense) and virus authors in the 90s, linking that to the focus on technical education in the 80s, lead by the Bulgarian communist party in an effort to revive communism through technology.

Near the end of the article I was pleasantly surprised to read my name, as a political candidate who advocates for digital e-government and transformation of the public sector. The article then ended with something that I’m in deep disagreement with, but that has merit, and is worth discussing (and you can replace “Bulgaria” with probably any country there):

Of course, the belief that all the problems of a corrupt Bulgaria can be solved through the perfect tools is not that different to the Bulgarian Communist Party’s old dream that central planning through electronic brains would create communism. In both cases, the state is to be stripped back to a minimum

My first reaction was to deny ever claiming that the state would be stripped back to a minimum, as it will not (risking to enrage my libertarian readers), or to argue that I’ve never claimed there are “perfect tools” that can solve all problems, nor that digital transformation is the only way to solve those problems. But what I’ve said or written has little to do with the overall perception of techno-utopianism that IT people-turned-policy makers are usually struggling with.

So I decided to clearly state what e-government and digital transformation of the public sector is about.

First, it’s just catching up to the efficiency of the private sector. Sadly, there’s nothing visionary about wanting to digitize paper processes and provide services online. It’s something that’s been around for two decades in the private sector and the public sector just has to catch up, relying on all the expertise accumulated in those decades. Nothing grandiose or mind-boggling, just not being horribly inefficient.

When the world grows more complex, legislation and regulation grows more complex, the government gets more and more functions and more and more details to care about. There are more topics to have policy about (and many to take an informed decision to NOT have a policy about). All of that, today, can’t rely on pen-and-paper and a few proverbial smart and well-intentioned people. The government needs technology to catch up and do its job. It has had the luxury to not have competition and therefore it lagged behind. When there are no market forces to drive the digital transformation, what’s left is technocratic politicians. This efficiency has nothing to do with ideology, left or right. You can have “small government” and still have it inefficient and incapable of making sense of the world.

Second, technology is an enabler. Yes, it can help solve the problems with corruption, nepotism, lack of accountability. But as a tool, not as the solution itself. Take open data, for example (something I’ve been working on five years ago when Bulgaria jumped to the top of the EU open data index). Just having the data out there is an important effort, but by itself it doesn’t solve any problem. You need journalists, NGOs, citizens and a general understanding in society what transparency means. Same for accountability – it’s one thing to have every document digitized, every piece of data – published and every government official action leaving an audit trail; it’s a completely different story to have society act on those things – to have the institutions to investigate, to have the public pressure to turn that into political accountability.

Technology is also a threat – and that’s beyond the typical cybersecurity concerns. It poses the risk of dangerous institutions becoming too efficient; of excessive government surveillance; of entrenched interests carving their ways into the digital systems to perpetuate their corrupt agenda. I’m by no means ignoring those risks – they are real already. The Nazis, for example, were extremely efficient in finding the Jewish population in the Netherlands because the Dutch were very good at citizen registration. This doesn’t mean that you shouldn’t have an efficient citizen registration system. It means that it’s not good or bad per se.

And that gets us to the question of technological utopianism, of which I’m sometimes accused (though not directly in the quoted article). When you are an IT person, you have a technical hammer and everything may look like a binary nail. That’s why it’s very important to have a glimpse on humanities sides as well. Technology alone will not solve anything. And my blockchain skepticism is a hint in that direction – many blockchain enthusiasts are claiming that blockchain will solve many problems in many areas of life. It won’t. At least not just through clever cryptography and consensus algorithms. I once even wrote a sci-fi story about exactly the aforementioned communist dream of a centralized computer brain that solves all social issues while people are left to do what they want. And argued that no matter how perfect it is, it won’t work in a non-utopian human world. In other words, I’m rather critical of techno-utopianism as well.

The communist party, according to the author, saw technology as a tool by which the communist government would achieve its ideological goal.

My idea is quite different. First, technology necessary for “catching up” of the public sector, and second, I see technology as an enabler. What for – whether it’s for accountability or surveillance, fight with corruption or entrenching corruption even further – it’s our role as individuals, as society, and (in my case) as politicians, to formulate and advocate for. We have to embed our values, after democratic debate, into the digital tools (e.g. by making them privacy-preserving). But if we want to have good governance, and to be good at policy-making in the 21st century, we need digital tools, fully understanding their pitfalls and without putting them on a pedestal.

The post Digital Transformation and Technological Utopianism appeared first on Bozho's tech blog.

Отчет за парламентарната ми дейност

Post Syndicated from Bozho original https://blog.bozho.net/blog/3815

Както писах веднага след изборите през юли, това, че не съм избран за народен представител изобщо не значи, че няма да върша работа по темите, заради които хората гласуваха за мен. В този кратък парламент нямаше време да бъде свършена много такава работа, но все пак смятам за редно да отчета по какво съм работил. Въпреки, че не съм бил депутат. Трябва да отбележа, че нито едно от нещата по-долу не съм ги свършил сам, разбира се – всичко е част от общата работа на Демократична България.

Много от нещата изглеждат като малки стъпки и дори бюрократични детайли. Но дяволът е детайлите. Електронното управление не работи не защото няма закон, не защото няма отговорна институция (има – ДАЕУ), не защото няма стратегически документи, не защото няма средства или защото не са обявени процедури, а защото някой детайл е объркан или пропуснат, някой не е преценил нещо навреме или някой не си е влязъл в правомощията, някой не е тълкувал правилно определен текст или пък самият законов текст има нужда от прецизиране. И разбира се, защото я е нямало политическата воля всички тези камъни да бъдат преместени от пътя.

  • Комисия по дигитализация, електронно управление и информационни технологии – създадохме такава комисия, която да контролира и направлява законодателния процес по дигиталните теми. Участвах на всяко заседание на тази комисия, активно вземайки думата, задавайки въпроси към институциите и подпомагайки председателя (Иво Мирчев от ДБ). Подпомагах и избора на дневен ред на комисията – какви теми да бъдат разглеждани, кой да бъде поканен и на какви въпроси да отговаря. По-надолу ще опиша трите основни въпроса, които разгледахме
  • Електронна идентификация – проектът за електронна идентификация е „забил“ в съда на Европейския съюз след обжалване на процедурата у нас. Повикахме МВР да отговорят как планират да реализират националната схема, дали са подготвени за реализиране на т.нар. „цифров портфейл“, предложен от Европейската комисия. В следствие на техните отговори преценихме различните варианти за действие и изпратихме писмо до премиера Янев, с което предлагаме да изпратят официално искане до съда на ЕС за по-бързо произнасяне, тъй като проектът е стратегически. Надявам се това да доведе до ускоряване на процеса, за да имаме и нови лични карти, и електронна идентичност възможно най-скоро.
  • План за възстановяване и устойчивост – проектите в плана за възстановяване и устойчивост, свързани с електронното управление, са няколко. Изискахме от Държавна агенция „Електронно управление“ и от вицепремиера Пеканов всички допълнителни данни, които не са част от архива и поискахме отговори на някои специфични въпроси. В следствие на това предложихме подобрения по някои от проектите, така че да се гарантира, че няма да бъдат изхарчени едни пари без резултат. Проектът за киберсигурност да бъде прецизиран, така че да е ясно за какво и колко пари отиват; в проекта за дигитализация на регистри да бъде включена и дейност за мигриране на малки регистри от тетрадки и ексели към централизирана система за управление на регистри; от проекта за широколентовия достъп да отпаднат 5G кулите по магистралите, защото на автономните автомобили това не им трябва, както пише в проекта, а и има други европейски източници на финансиране.
  • НСИ и преброяването – повикахме НСИ да дадат обяснение какво и защо се е случило със системата за преброяването. Обобщение писах във Фейсбук и тук, а заключението е, че трябва повече централна координация и по-добра подготовка с оглед киберсигурността на ключови системи.
  • ЦИК и машинното гласуване – повикахме и ЦИК в комисията, за да обсъдим машинното гласуване при избори 2в1. Там предложих няколко неща – тестове за ползваемост (A/B тестове), така че интерфейсът да е максимално удобен на избирателите; извадкова проверка на хешовете на машините с външен инструмент, за да не разчитаме само на това, което те самите разпечатват; системният образ на софтуера, който се инсталира на всички машини, да бъде компилиран публично. Подчертах и задължението изходният код да е наличен за заинтересованите страни (по закон – експерти, излъчени от партиите/коалициите, гражданския и академичния сектор). Ще следим оттук нататък ЦИК да спази това задължение.
  • Законопроект за изменение на Закона за електронно управление – предлагаме няколко неща, като основните са две – доставчици на обществени услуги да участват в електронния обмен на документи с администрацията, ако са част от административна услуга (напр. ако за да получите разрешение за ползване на търговски обект ви изискват партида от ЕРП, това да не става с хвърчаща бележка, а служебно, по електронен път); администрациите да са длъжни да водят малки и прости регистри в централизирана система, отговаряща на всички съвременни изисквания, а не в ексел, на тетрадки или в някакви стари и пробити системи, както е в момента. Законопроектът получи подкрепя от всички партии, от администрацията и от браншови организации, в рамките на проведеното обществено обсъждане.
  • Законопроект за отпадане на стикерите за технически преглед – новите стикери с чип, които са скъпи и грозно стоят на средата на предното стъкло, са напълно излишни. Предложихме отпадането им и замяната им с проверка в централизираните регистри по номер на автомобил. Повече за проблемите с RFID чиповете съм писал тук. Подготвихме и сходен законопроект за отпадане на стикерите за Гражданска отговорност, но тъй като стана ясно, че няма как да мине, не го внесохме.
  • Законопроект за автоматично получаване на EORI номер (вместо да го заявяваме през неудобния сайт на агенция Митници)
  • Законопроект за уреждане и ограничаване на безконтролното записване на данни за преминаващи автомобили от камерите на АПИ – към настоящия момент АПИ събира данни за това кой автомобил, къде и кога е преминал и ги съхранява на база на вътрешен акт, без да има гаранции кой има достъп, за колко време се съхраняват и за какво се ползват. С предложението уреждаме тези неща, включително уведомление на шофьорите, чиито данни са били използвани след като са били събрани.
  • Въпрос към ГД ГРАО за отказите за предоставяне на данни – Националната база данни „Население“ е основен компонент на електронното управление. Повечето институции трябва да имат право да четат данни оттам – по ЕГН да получат три имена и адрес. Общините, например, често имат нужда от тези данни, за да предоставят общински услуги (при записване в детски градини, където адресът на родителите има значение, вместо родителите да носят удостоверение, общината да го събира служебно). За съжаление през годините има доста оплаквания, че ГД ГРАО отказва достъп. От отговорът на ГРАО излиза, че това наистина е така – около 1/4 от заявленията за достъп са получили отказ. Изводът от това е, че трябва да се промени Закона за гражданска регистрация, така че да не позволява превратно тълкуване, така че общините да могат да си вършат работата (особено предвид, че те са тези, които вкарват данните в регистъра), и разбира се – данните да бъдат защитени от изтичане
  • Въпрос до премиера дали в Администрацията на министерския съвет документи се обменят електронно – отдавна е факт, че Администрацията на министерски съвет е една от най-недигиталните институции. Това е проблем на практическо и на символно ниво – не може да говорим за е-управление, а в „сърцето“ на управлението да се разнасят колички с папки по етажите. Отговорът, все пак е, че АМС е започнала (най-накрая!) поетапно да въвежда електронен документооборот. Надявам се натискът за това да продължи и този план да бъде изпълнен в следващите месеци

За два месеца – толкова. Ясно е, че нищо не може да бъде доведено до край. Но смятам, че помогнах за някои важни стъпки. Остават още много, много неща, разбира се. И трябва широк дебат за цялостната структура на електронното управление – къде стои ДАЕУ, къде стои системният интегратор, кой какво и как възлага, кой контролира. Тази структурна промяна ще трябва да започне в следващото Народно събрание.

Материалът Отчет за парламентарната ми дейност е публикуван за пръв път на БЛОГодаря.

Какви са проблемите на системата за преброяването?

Post Syndicated from Bozho original https://blog.bozho.net/blog/3811

Проблемите на НСИ са сложни и многопластови и не могат да се обяснят просто с посочване на някого с пръст. Трябва, обаче, да търсят дългосрочни решения, а не оправдания.

Струва ми се, обаче, в ИТ общността си представя нещата малко по-просто, отколкото са. Това не е „един уебсайт“, на който просто трябва да сложиш достатъчно хардуер, за да работи. Ето няколко публично известни факта, които да помогнат интерпретацията:

  • НСИ е направил поръчка за готова система за преброяване, а не за разработка на такава. Като цяло разумно решение. Местният партньор на шведската фирма „производител“ е СкейлФокус, които е трябвало да направят инсталация, конфигурация и поддръжка. Много често компании предпочитат да имат местни партньори, при които отива процент от продажбата, т.нар. two tier (или понякога three tier) distribution model. Цената е за лиценз, инсталация и конфигурация и като цяло изглежда разумна. Функционалностите са доста повече от
    онлайн форми (на който му е интересно, техническото задание, предложението и договорът са на сайта на НСИ)
  • DDoS атаката е сериозна – ако наистина 250 гигабита в секунда са се „изсипали“ срещу системата, то на чисто софтуерно ниво няма какво да се направи – „тръбата“ се запушва, дори приложението да може да обработи данните. Засега няма причина да смятаме, че тази информация е грешна, най-много да е малко преувеличена, но дори да е наполовина, пак е значителна. Не съм съгласен, че „какво толкова сложно има да се защити една система“ – това не е софтуерен проблем, а мрежови. И няма прости и евтини решения.
  • НСИ не са били подготвени за такава атака, а е трябвало. Ползването на CloudFlare е недостатъчна мярка за критичността и репутационните щети. Обикновено проблемът с CloudFlare е не самият CloudFlare, а това, че по други данни (исторически и настоящи DNS записи и просто логическо мислене) може да се прескочи CloudFlare.
  • Тук обаче ще вдигна нещата едно ниво по-нагоре – това не е проект на НСИ, това е национален проект. НСИ просто е натоварен с неговото изпълнение. На ниво държава изгелжда липсва адекватна подготовка за защита от DDoS. Държавна агенция „Електронно управление“ и ресорните вицепремиери до момента е трябвало да осигурят такава не само на НСИ, но и за всички системи. Тя не е евтина, но работи (чрез т.нар. scrubbing центрове, които „почистват“ мръсния трафик преди да го изпратят към системите.) Кадровото осигуряване също е важна тема – колко ИТ експерти има НСИ и на какво заплащане и можем ли да очакваме да свършат всичко? Това също е системен проблем в държавата.
  • DDoS атаките рядко водят до изтичане на данни (сами по себе си – никога, но понякога се ползват за димна завеса, прикрирваща други действия; засега не изглежда да е такъв случаят).
  • съдейки по съобщенията за грешка, които излизаха в предните два дни, е имало и чисто интеграционни проблеми за проверката на въведените лични данни. За тези проблеми няма добро оправдание, а причината е липсата на координация между институциите и липсата на отговорен за процеса.

На следващото заседание на комисията по дигитализация в Народното събрание ще изясним всички тези въпроси. А следващото постоянно правителство трябва да ги реши системно.

Материалът Какви са проблемите на системата за преброяването? е публикуван за пръв път на БЛОГодаря.

Obtaining TLS Client Certificates In Spring Integration

Post Syndicated from Bozho original https://techblog.bozho.net/obtaining-tls-client-certificates-in-spring-integration/

Spring Integration is a very powerful and extensible framework for, well, integrations. But sometimes it’s not trivial how to get some information that yo need. In my case – a certificate used for mutual authentication in a TLS (syslog over TLS) connection. You have a Java method that receives a Message and ideally you’d want to get the certificate chain used by the client to authenticate itself (e.g. you may need to extract the CN).

Fortunately, Spring Integration is flexible. And it can be done, but it’s a bit convoluted. I’ll use XML notation, but the same can be achieved through Java config.

<bean id="nioConnectionSupport" class="com.yourcompany.util.net.TLSMutualNioConnectionSupport">
        <constructor-arg ref="sslContextSupport" />
        <constructor-arg value="false" />
</bean>
<bean id="interceptorFactoryChain" class="org.springframework.integration.ip.tcp.connection.TcpConnectionInterceptorFactoryChain">
        <property name="interceptors">
            <bean class="com.yourcompany.util.net.TLSSyslogInterceptorFactory" />
        </property>
</bean>

<int-ip:tcp-connection-factory id="tlsConnectionFactory" type="server" port="${tcp.tls.port}"
                                   using-nio="true" nio-connection-support="nioConnectionSupport"
                                   single-use="false" interceptor-factory-chain="interceptorFactoryChain" />

The sslContextSupport would typically be a org.springframework.integration.ip.tcp.connection.DefaultTcpSSLContextSupport or a custom implementation (e.g. if you want to use a “blind” trust store)

Then you’d need the two classes. You can check them at their respective gists: TLSSyslogInterceptorFactory and TLSMutualNioConnectionSupport.

What do these classes do? The TLSSyslogInterceptorFactory sets a new header for the message that contains the client ceritficates. The TLSMutualNioConnectionSupport class sets the “wantClientAuth” option on the SSL Engine. There is another option – “needClientAuth” which would for client authentication, rather than just support it. Depending on the use case you can use one or the other.

Then you can obtain the certificates at your handler method via:

Certificate[] certificates = (Certificate[]) message.getHeaders().get(TLSSyslogInterceptorFactory.TLS_CLIENT_CERTIFICATES);

A small tip I wanted to share to help the next one trying to achieve that.

The post Obtaining TLS Client Certificates In Spring Integration appeared first on Bozho's tech blog.