Author Archives: Божидар Божанов

Simple Things That Are Actually Hard: User Authentication

от Божидар Божанов

лиценз CC BY

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? Configuring subset of AD/LDAP users to authenticate based on certain group memberships?
Force 2FA by admin configuration – implement time window for activating 2FA after a global option is enabled?
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, if there’s a load balancer / reverse proxy, does it support it and how to forward certificate details?
Require account activation or let the user login immediately after registration? Require account approval by back-office staff?
Initial password setting for accounts created by admins – generate initial password and force changing it on first login? Don’t generate password and start from a password reset flow?
Login anomalies – how to detect them and should you inform the user? Should you rely on 3rd party tools (e.g. a SIEM), or have such functionality built-in?

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

от Божидар Божанов

лиценз CC BY

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.

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

от Божидар Божанов

лиценз CC BY

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

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

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

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

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

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

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

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

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

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

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

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

от Божидар Божанов

лиценз CC BY

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

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

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

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

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

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

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

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

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

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

от Божидар Божанов

лиценз CC BY

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

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

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

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

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

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

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

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

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

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

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

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

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

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

П.П. Въпреки горееизложеното, осъзнаваме отговорността си като ръководство на партията. В такива моменти е редно да бъдат подадени оставки, което и направихме – Христо Иванов и изпълнителният съвет, от който съм част, подадохме оставки.

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

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

от Божидар Божанов

лиценз CC BY

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

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

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

Доставка на празни машини
Получаване на изходния код
Компилиране на изходния код до системен образ
Електронно подписване на системния образ
Записване на подписания системния образ на флашка
Инсталиране на системния образ на всички машини (отключване на машините, в случай, че на тях е бил инсталиран друг системен образ, подписан с други ключ)
Провизиране на данните за конкретния избор върху машината (кандидатски листи, номер на секция, номер на машина)
Генериране на ключове върху смарт-карти (тези белите, с които секционните комисии подписват)
Комплектоване на смарт-картите и техните ПИН-кодове
Транспортиране на машините и смарт-картите до РИК, съответно до секциите
Стартиране на изборния ден
Гласуване
Приключване на изборния ден и подписване на протокола (както на хартия, така и електронно)
Транспортиране на хартиения протокол, смарт-картите и флаш-паметите с машинния протокол
Проверка на протокола и въвеждането му в системата за машинна обработка
Сумиране и обявяване на резултата

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hypotheses About What Happened to Facebook

от Божидар Божанов

лиценз CC BY

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.
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.
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

от Божидар Божанов

лиценз CC BY

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.

Obtaining TLS Client Certificates In Spring Integration

от Божидар Божанов

лиценз CC BY

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.

Every Serialization Framework Should Have Its Own Transient Annotation

от Божидар Божанов

лиценз CC BY

We’ve all used dozens of serialization frameworks – for JSON, XML, binary, and ORMs (which are effectively serialization frameworks for relational databases). And there’s always the moment when you need to exclude some field from an object – make it “transient”.

So far so good, but then comes the point where one object is used by several serialization frameworks within the same project/runtime. That’s not necessarily the case, but let me discuss the two alternatives first:

Use the same object for all serializations (JSON/XML for APIs, binary serialization for internal archiving, ORM/database) – preferred if there are only minor differences between the serialized/persisted fields. Using the same object saves a lot of tedious transferring between DTOs.
Use different DTOs for different serializations – that becomes a necessity when scenarios become more complex and using the same object becomes a patchwork of customizations and exceptions

Note that both strategies can exist within the same project – there are simple objects and complex objects, and you can only have a variety of DTOs for the latter. But let’s discuss the first option.

If each serialization framework has its own “transient” annotation, it’s easy to tweak the serialization of one or two fields. More importantly, it will have predictable behavior. If not, then you may be forced to have separate DTOs even for classes where one field differs in behavior across the serialization targets.

For example the other day I had the following surprise – we use Java binary serialization (ObjectOutputStream) for some internal buffering of large collections, and the objects are then indexed. In a completely separate part of the application, objects of the same class get indexed with additional properties that are irrelevant for the binary serialization and therefore marked with the Java transient modifier. It turns out, GSON respects the “transient” modifier and these fields are never indexed.

In conclusion, this post has two points. The first is – expect any behavior from serialization frameworks and have tests to verify different serialization scenarios. And the second is for framework designers – don’t reuse transient modifiers/annotations from the language itself or from other frameworks, it’s counterintuitive.

The post Every Serialization Framework Should Have Its Own Transient Annotation appeared first on Bozho's tech blog.