artykuły

Myślenie stadne, a sprawa słynnego Kalkulatora Wyborczego

3:46
czw, 20 listopad 2014
Opisuję i podsumowuję sprawę tzw. Kalkulatora Wyborczego firmy Nabino o którym zrobiło się głośno po Wyborach Samorządowych 2014 r.

Falę krytyki, która została skierowana pod adresem łódzkiej firmy Nabino (autora Kalkulatora Wyborczego) można nazwać jednym słowem - porażająca. Jednak, jak zawsze w takich wypadkach bywa - prawda ginie w natłoku „myślenia” stadnego. Spowodowane jest to tym, że bardzo niewiele osób w społeczeństwie umie czytać kod programu, a jeszcze mniej osób zna się choć trochę na kryptografii. A tutaj potrzeba ludzi należących do iloczynu tych zbiorów. Ich głos ginie, zagłuszany bardziej sensacyjnie brzmiącymi hasłami, że „można się włamać i sfałszować wybory”. W tym artykule postaram się powiedzieć jak było i jak jest. Udało mi się także dotrzeć do kilku testerów i prezesa firmy Nabino, który specjalnie dla Lukas’ Home Page zajął stanowisko w interesujących mnie kwestiach.

Zawsze byłem uczony bronić słabszych, w tym przypadku pod obiektywną, lekką obronę, wezmę firmę Nabino, bo mimo kompletnej porażki ich oprogramowania, nie zasłużyła sobie na aż taką krytykę uwzględniwszy ile czasu mieli na przetestowanie programu. A wina, jak zwykle, leży po obu stronach - mówię o serwerach KBW. Tyle, że ta druga strona stara się wybielać i zwalać całą winę na tę pierwszą stronę.

Firma Nabino, jako jedyna podjęła się stworzenia oprogramowania określonego w przetargu. Decyzję o rozstrzygnięciu przetargu wydano 4 sierpnia 2014 r. Pierwsze wybory w których użyto Kalkulatora (wybory uzupełniające do senatu) odbyły się 7 września 2014 r, kolejne - nieszczęsne Wybory Samorządowe - miały miejsce kilka dni temu - 16 listopada. To ponad miesiąc - kupa czasu, prawda? /sarkazm/ Jeśli chodzi o samo napisanie aplikacji - można by powiedzieć: „przydało by się więcej, ale jakoś się wyrobimy”. Nawet bardzo pasuje tu znane powiedzenie, że „każda praca wymaga tyle czasu ile na nią jest”. A to w końcu aplikacja budowana na komponentach, podliczająca i przesyłająca informacje na serwer - nic strasznie skomplikowanego. Natomiast taki termin jaki został określony przez KBW - cóż… sami się o to prosili. Nijak ma się on do wdrożenia oprogramowania, z włączeniem w to testów i audytów. Nie ma szans. Do listopada też nie. Na to potrzebne byłoby przynajmniej cztery miesiące. Z drugiej strony można byłoby powiedzieć, że Nabino niepotrzebnie startowała w przetargu - i mieć tutaj całkiem sporo racji (ale Volenti non fit iniuria! - jak mawia JKM za Rzymianami).

Ogłoszenie o wyłonieniu zwycięzcy przetargu

Około wrześniowych wyborów czytałem depesze PAPu z testów systemu, w których kilka tysięcy użytkowników-testerów przeklinało system. Prezes firmy Nabino wydał wtedy nawet stosowne oświadczenie:

http://samorzad.pap.pl/depesze/wybory_2014/145363/Sprawne-liczenie--Publikujemy-oswiadczenie-przedstawiciela-firmy-Nabino

Wtedy tak to działało. I musiało tak działać. Ilość wyjątków życia codziennego, nieuwzględnionych przy tworzeniu modelu (czyli wycinka rzeczywistości) projektu systemu zawsze mści się w najmniej odpowiednim momencie - to parafraza jednego z tzw. praw Murphy’ego. Tak też było w tym przypadku - o czym świadczą liczne komentarze z tamtego okresu:

Dzisiaj cała noc w plecy, problemy z drukowaniem (6 stron tekstu generował do docx 2 min.), wysyłaniem (ciągła utrata połączenia). Do tego jak wysłało się błędny raport i trzeba było zrobić poprawkę to nie można było bo suma kontrolna obu była identyczna (!), prawdopodobnie nie zawierała żadnych danych czasowych.

Komentarz z niebezpiecznik.pl

Ale przejdźmy do sedna - bo jest ciekawsze.

Sedno sprawy

W trakcie wyborów, ktoś wrzucił na GitHub zde(pośrednio)kompilowany kod kalkulatora wyborczego. Nie ma w tym nic dziwnego. Każdy program można zdekompilować. A te napisane w .NET czy w Javie (czyli językach, których kompilatory dokonują tłumaczenia do kodu pośredniego (dla Javy bajtkodu, dla .NET tzw. IL) nawet z nieco większym sukcesem (czyt. przejrzystością kodu) [w przypadku Javy często udaje się dostać nawet - uwaga - komentarze programistów w kodzie! - ostatnio miałem właśnie taką sytuację]. I zaciemnianie kodu niewiele w tym pomaga, a z całą pewnością spowalnia aplikację. Kalkulator został jednak dostarczony do odbiorców po kompilacji w trybie DEBUG (zamiast RELEASE). Dodatkowo, skompilowano go z tzw. symbolami PDB zawierającymi metadane dotyczące prawdziwych nazw klas, metod, zmiennych itp. wraz z ich powiązaniem z odpowiadającymi im numerami linii w kodzie źródłowym. Dzięki temu, analiza tak zde(pośrednio)kompilowanego kodu była dużo łatwiejsza i mniej czasochłonna (ponieważ nie trzeba było „odgadywać” która funkcja co robi - ich nazwy mówiły wszystko).

Oglądając kod, należy uczciwie powiedzieć, że jest on kiepsko napisany. Rzuciły mi się w oczy rzeczy takie jak: modyfikowanie XMLa za pomocą funkcji zamieniającej ciągi tekstowe (zamiast działania na drzewie DOM), brak jakiegokolwiek rozdzielenia logiki modelu od kodu prezentacji danych (to wszystko jest ze sobą wymieszane) oraz śmieszne, olbrzymie bloki try try try try try catch catch catch catch catch :) I o ile można by było zrzucić wszystko na dekompilator, o tyle w przypadku włączonych symboli PDB - no niestety - ten kod tak właśnie został napisany.

Try try try try try catch catch catch catch catch... :)

Na uwagę zasługują również dane wprowadzane na sztywno w kodzie. To rozwiązanie stosuje się nadal… przy programowaniu mikrokontrolerów. W innych wypadkach należy starać się go unikać - zaciemnia to tylko kod.

Dane wprowadzane w kodzie Adresy serwerów

Całość wygląda naprawdę na pisaną w niesamowitym pośpiechu, po łebkach. Mimo wszystko jednak (wnioskuję po znajomości dość egzotycznych funkcji) że nie był to pierwszy projekt pisany przez tego autora/autorkę. Autor na pewno ma już na koncie kilka projektów w .NET. Jednak styl pisania kodu przypomina styl dawnego, proceduralnego PHP (wersje < 5).

Prawdopodobnie pierwszy i najgłośniejszy - i chyba jedyny wtedy - głos analityczny dot. bezpieczeństwa zabrał p. Marek Małachowski, pisząc:

Poświęciłem dwie godziny na analizę kodu programu do obsługi komisji wyborczych i kilka testów. Program do logowania wymaga klucza cyfrowego (pliku PEM) o odpowiednio przygotowanych parametrach. Programu nie interesuje przez kogo jest ten klucz podpisany. Więc używając OpenSSL można klucz taki samodzielnie wygenerować.

Przejrzałem instrukcję obsługi programu, gdzie podano przykład logowania. Używając danych pokazanych na obrazkach w instrukcji, można wygenerować sobie klucz logowania do programu jako członek komisji w Bałtowie (gdziekolwiek to jest). Zalogowanie się jako dowolny członek dowolnej innej komisji nie wymaga wyjątkowej wiedzy.

Czyli dowolna osoba, która miała dostęp do komputera z programem "Kalkulator1", mogła się do niego zalogować jako dowolny członek komisji i dokonać w niezauważony sposób zmian w protokołach zapisanych na tym komputerze. Członkowie komisji mogli logować się jako ktoś inny, ale mogła to też zrobić osoba zupełnie z zewnątrz, nie znająca żadnego hasła, bez jakiejkolwiek autoryzacji. Wystarczy, że sama sobie prędzej swój własny klucz cyfrowy zrobiła.

https://www.facebook.com/adekmm/posts/10203022862521117

Czytając ten post pokiwałem troszkę głową. Bowiem wyniki głosowania w komisji są jawne i każda komisja je wywiesza. Oczywistym dla mnie było więc, że certyfikatów używa się nie do logowania i szyfrowania, ale do cyfrowego podpisania protokołu/sprawozdania po uprzednim zweryfikowaniu danych. Utwierdził mnie w tym kod, który w certyfikacie sprawdza… jedynie datę jego ważności - dla ciekawych - kod poniżej (w projekcie znajdują się chyba trzy funkcje o nazwie isActiveLicense - każda z nich sprawdza certyfikat w ten sposób):

public bool isActiveLicense(string license) { bool response = false; try { System.Security.Cryptography.X509Certificates.X509Certificate certtmp = new System.Security.Cryptography.X509Certificates.X509Certificate(license); System.DateTime a = new System.DateTime(1, 1, 1, 0, 0, 0); System.DateTime fromDate = System.Convert.ToDateTime(certtmp.GetEffectiveDateString()); if (fromDate == a) { System.Threading.Thread.Sleep(1000); fromDate = System.Convert.ToDateTime(certtmp.GetEffectiveDateString()); } System.DateTime toDate = System.Convert.ToDateTime(certtmp.GetExpirationDateString()); if (toDate == a) { System.Threading.Thread.Sleep(1000); toDate = System.Convert.ToDateTime(certtmp.GetEffectiveDateString()); } int result = System.DateTime.Compare(fromDate, System.DateTime.Now); int result2 = System.DateTime.Compare(System.DateTime.Now, toDate); if (result <= 0 && result2 <= 0) { response = true; } } catch (System.Security.Cryptography.CryptographicException) { } return response; }

Uruchomienie programu wymaga podania swojego certyfikatu (RSA 1024 bit) - można go „sfałszować” - sami nawet to za chwilę zrobimy. Logowanie na serwer to osobny proces (wymagany login i hasło). Taką technikę wykorzystuje na przykład oprogramowanie Asseco Poland do płatności ZUS. Dokument podpisywany jest więc prywatnym kluczem przewodniczącego, a ktoś posiadający klucz publiczny przewodniczącego (np. serwer KBW) jest w stanie dzięki temu zweryfikować czy od momentu podpisywania dokument się zmienił czy nie i czy faktycznie przewodniczący się z nim zapoznał. Rzeczą, której tutaj Pan Marek nie napisał była kwestia weryfikacji CA (czyli Urzędu Certyfikacji, od ang. Certificate Authority). Co z tego, że protokół można było podpisać wygenerowanym przez siebie kluczem, skoro nie był on certyfikowany przez odpowiedni Urząd Certyfikacji - w tym wypadku KBW. Po wysłaniu tak podpisanego protokołu na serwer, najprawdopodobniej z miejsca byłby on odrzucony i nie wykorzystany do obliczeń (z racji, że nie posiada certyfikatu KBW). W domu nie można wygenerować sobie podpisu cyfrowego z certyfikatem KBW. Tylko KBW ma klucz prywatny, który umożliwia taką operację. I to właśnie KBW rozdawało certyfikowane podpisy użytkownikom „Kalkulatora”. Tak to działało. Mój tok rozumowania (tuż przed momentem publikacji artykułu)  potwierdził p. Maciej Cetler - prezes firmy Nabino:

nie, serwer [przesłanych plików - dop. Lukas] nie akceptował i wykorzystywał do obliczeń przesyłanych protokołów na licencjach innych niż podpisanych przez CA KBW. Podobna infrastruktura jest wykorzystywana w przypadku np. płatnika (i również korzystają z OpenSSL).

Wypowiedź Pana Marka natomiast dużo bardziej się rozjaśniła, kiedy serwis wGospodarce opublikował z nim wywiad. Tam już wyraźnie widzimy o co chodziło - jego post po prostu został powszechnie źle zrozumiany i podsycony:

Marek Małachowski Rozmowa ze mną. Chyba jedyna publikacja, która mówi tak konkretnie co znalazłem i nie eskaluje tego.

http://wgospodarce.pl/informacje/17261-marek-malachowski-na-pewno-powinien-byc-przeprowadzony-audyt-calego-oprogramowania
Na Facebooku, Pan Marek pisze:
Marek Małachowski Fakty TVN prezentują rzeczywistość po swojemu. Ponoć uważam "że dzięki kilku trickom każdy może wpłynąć na wynik głosowania".
Trudno się nie zgodzić. A po poniższej, rozszerzającej wypowiedzi, z mojej strony nastąpiła pełna zgoda:
W porządku - załóżmy, że jestem programistą. Czy mogę w takim razie, będąc już w programie, wpływać na wynik wyborów? Nie mam tu na myśli fałszerstw, ale nieodpowiedzialną zabawę "w hakera" paraliżującą proces wyborczy.

To dość skomplikowany scenariusz. Musiałby Pan przede wszystkim w odpowiednim momencie dostać się do komputera w komisji wyborczej. W czasie pomiędzy wprowadzaniem danych do protokołów a ich wysłaniem przez przewodniczącego komisji. I do tego, wyniki przez Pana zmienione musiałby zatwierdzić przewodniczący tuż przed samym wysłaniem tych wyników na serwer. Czyli jak widać, nie jest to zadanie łatwe. Tym bardziej w momencie, gdy ze względu na inne błędy systemu, przewodniczący ma świadomość, że należy ten program i te protokoły skrupulatnie kontrolować.

Moim zdaniem jest to spory błąd w bezpieczeństwie, jednak nie nazwę go krytycznym. Przewodniczący ma obowiązek pilnowania dostępu do komputera i swojego podpisu. Wyniki i tak musi podpisać swoim kluczem uprzednio je weryfikując. Podsumowując więc: przyjmowanie wszystkiego i postawienie na weryfikacje po stronie serwera to całkiem dobre rozwiązanie. Przy projektowaniu tego typu systemów klientom nie ufa się nigdy. Mimo wszystko, miło byłoby jednak gdyby dostęp od strony klienckiej został nieco lepiej przemyślany i bardziej ograniczony (nie powodując jednocześnie dodatkowych utrudnień w użytkowaniu aplikacji).
Jak widać więc, cała afera została „nieco” rozdmuchana do rozmiarów zdalnego fałszowania głosów przez hackerów.

Pan Maciej Cetler (prezes Nabino) pisze również:

możliwe jest wypełnienie protokołu licencją przygotowaną przez dowolną aplikację opartą o kryptografię z odpowiednio skonstruowanym OU***. Takie były założenia architektoniczne natomiast:
1) nie przyjmuje niczego bez podpisu przez odpowiednie CA (KBW)
2) przyjmujemy WYŁACZNIE paczki, które są podpisane certyfikatami znajdującymi się po stronie serwera.
*** Dla czytelników ciekawych czym jest wspomniane przez Pana Macieja „OU” - proste wytłumaczenie: to skrót od „Organization Unit” i jest to pole, które podajemy podczas generowania tzw. „żądania wystawienia certyfikatu” (zaraz się tym zajmiemy).

Interesowało mnie również: kto odpowiadał za architekturę sprzętową, która zawiodła po całości (zapchane, niewystarczająco wyskalowane serwery) - okazuje się, że KBW (co miałem okazję wywnioskować również pośrednio z innych dokumentów):

pisaliśmy frontend i backend z tym, że całość np. do kalkulatora była pisana przez KBW. oprogramowanie serwerowe jak również oprogramowanie do wirtualizacji dostarczyło KBW. Ilość serwerów, ich rodzaj, sieciówka, infrastruktura leży po stronie KBW. Pozdrawiam,
Jak się okazało nie był to pierwszy problem z serwerami. W ostatnich testach były problemy z łączami światłowodowymi, a dokładniej (podobno) ze switchem światłowodowym.

Robimy swój certyfikat aby uruchomić program

Najpierw musimy ściągnąć paczkę OpenSSL, która pozwoli wygenerować nam odpowiedni klucz:
http://gnuwin32.sourceforge.net/packages/openssl.htm
Jeśli czytasz ten artykuł po dłuższym czasie od jego publikacji, przydatna może okazać się również paczka z samym Kalkulatorem Wyborczym (dodałem do niej wersję zde[pośrednio]kompilowaną).
Po instalacji OpenSSL, uruchamiamy wiersz poleceń Windows i przechodzimy do folderu bin, w katalogu, w którym zainstalowaliśmy OpenSSL. Teraz musimy wygenerować swój klucz prywatny o szerokości 1024 bitów z DES3 (takie wartości ustaliłem badając certyfikaty używane przez program - zauważcie, że gdy podamy do programu klucz dłuższy niż 1024 bity, nastąpi przepełnienie tablicy i program zgłosi wyjątek :). Zacznijmy więc wpisując:

openssl genrsa -des3 -out -kluczyk.key 1024

Następnie, jeszcze przed wygenerowaniem właściwego certyfiktu, musimy wygenerować tzw. „żądanie certyfikatu”, czyli CSR. W kodzie programu Kalkulator wygląda to tak: public void generateCSR(string electoralEampaign, string user, string password) { X509Name name = new X509Name("C=PL, ST=Mazowieckie, L=Warszawa, O=KBW, E=-, OU=" + electoralEampaign + ", CN=" + user); RsaKeyPairGenerator keyGenerator = new RsaKeyPairGenerator(); RsaKeyGenerationParameters param = new RsaKeyGenerationParameters(BigInteger.ValueOf(3L), new SecureRandom(), 2048, 25); keyGenerator.Init(param); AsymmetricCipherKeyPair ackp = keyGenerator.GenerateKeyPair(); Pkcs10CertificationRequest csr = new Pkcs10CertificationRequest("SHA1WITHRSA", name, ackp.Public, null, ackp.Private); System.Text.StringBuilder CSRPem = new System.Text.StringBuilder(); PemWriter CSRPemWriter = new PemWriter(new System.IO.StringWriter(CSRPem)); CSRPemWriter.WriteObject(csr); Przy generowaniu CSR (a więc żądania certyfiaktu), zostaniemy zapytani o szereg danych. Musimy je odpowiednio uzupełnić. Ważne jest zwłaszcza pole OU (czyli wspomniane wcześniej Orgaizational Unit Name). Należy tam wpisać odpowiedni identyfikator komisji wyborczej:

openssl req -new -key kluczyk.key -out kluczyk.csr
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:Mazowieckie
Locality Name (eg, city) []:Warszawa
Organization Name (eg, company) [Internet Widgits Pty Ltd]:KBW
Organizational Unit Name (eg, section) []:20140907/000000/SNTU/82-260604-O
Common Name (eg, YOUR name) []:Lukasz Wyporek
Email Address []:lukas.home.page@gmail.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

I dopiero wtedy, korzystając z dwóch powyżej wygenerowanych plików, możemy wygenerować właściwy certyfikat (oczywiście nie będzie on podpisany przez KBW):

openssl x509 -req -days 730 -in kluczyk.csr -signkey kluczyk.key -out kluczyk.crt
Po wczytaniu go do programu Kalkulator, przejdziemy przez planszę go wymagającą:
Po przyjęciu certyfikatu

429 270 tysięcy złotych i zero groszy!

Fakt wydania pół miliona na coś co można byłoby zrobić za 6-7 tysięcy [chyba, aż tak bardzo się nie mylę, co?] (mówię o samym kalkulatorze, bez testów, przyjęć i szkoleń!) jest…. Ykhm…. „Normalny” w Polsce :) Nie wiem czy śledzicie rządowe wydatki czasami - ale strona za 2 mln dla jakiegoś ministerstwa to jest normalka. Ceny takie jednak są w dużej części usprawiedliwione dlatego, że ministerstwo marnotrawi pieniądze i zamawia do strony internetowej własną serwerownie, płacąc za 10 lat do przodu za opiekę nad nią. Czyżbyśmy mówili o portalu dla bezdomnych za 49mln? /nie… tak naprawdę było to 3,3mln i był to bardziej rozbudowany system/ Tak więc znowu - ludzie widzą drzazgę finansową, a nie widzą belki. W przypadku Kalkulatora, koszty rosły poprzez wliczanie do nich (obowiązkowej pozycji przetargu) - uroczystej kolacji na kilkaset osób po odbytym szkoleniu:

Zapis o uroczystej kolacji w specyfikacji przetargu... Tak, objąłem to w tag <details> :)
11. Przeprowadzenie minimum 2-dniowego szkolenia, dla około 150 - 200 użytkowników zamawianego oprogramowania, w terminie do 17 października 2014r., (w zakres szkolenia wchodzi także uroczysta kolacja dla uczestników szkolenia).
Źródło: specyfikacja przetargu
Warto w tym miejscu zaznaczyć, że to nie ceny firm są z kosmosu, tylko przyzwolenie na nie i wymagania przetargowe instytucji Państwowych. Akurat w tej kwestii nie mam do Nabino żadnych zastrzeżeń - każdy na ich miejscu sięgnąłby po te pieniądze.

Pozostałe założenia przetargu:

  • Moduł kalkulatora wyborczego dla obsługi obwodowej komisji wyborczej w wyborach samorządowych,
  • Moduł kontroli spływu protokołów wyników głosowania w obwodzie,
  • Moduł przyjmowania danych elektronicznych z protokołów wyników głosowania w obwodzie przesłanych przez moduł kalkulatora wyborczego,
  • Moduł obsługi organu wyborczego (terytorialnej komisji wyborczej, komisarza wyborczego i Państwowej Komisji Wyborczej) na obszarze właściwości organu,
  • Moduł ustalania wyników głosowania i wyników wyborów,
  • Oprogramowanie do zarządzania uprawnieniami do obsługi informatycznej wyborów w oparciu o bazę LDAP udostępnioną przez Zamawiającego,
  • Oprogramowanie obsługi infrastruktury klucza publicznego w zakresie wystawiania i udostępniania certyfikatów,
  • Systemu pobierania danych o komitetach wyborczych, listach kandydatów i kandydatach oraz obwodach, okręgach i składach komisji z serwisów udostępnionych przez Zamawiającego,
  • Wykonanie eksportu danych, zapewniający przeniesienie danych dotyczących komitetów wyborczych, list kandydatów i kandydatów, obwodów głosowania, okręgach wyborczych i wyników głosowania, wyników podziału mandatów do archiwum (zaimplementowanego jako relacyjna baza danych),
  • Wykonanie modułu obsługi wprowadzenia, przyjmowania danych o liczbie wyborców, którzy wzięli udział w głosowaniu w trakcie głosowania, nadzoru nad przekazywaniem, kontroli poprawności,
  • Przeprowadzenie szkolenia użytkowników zamawianego oprogramowania,
  • Administrowanie infrastrukturą teleinformatyczną w siedzibie Zamawiającego i w zewnętrznym centrum przetwarzania.
Zainteresowanym, polecam przejrzeć samą rozpiskę przetargu, oraz pytania do niego.

Teoria spiskowa (znajomy mnie wykpił!)

Każdy ma swoją. Moja teoria spiskowa koncentruje się na umyślnym skompromitowaniu systemu informatycznego, żeby nigdy nie powstała możliwość głosowania przez Internet (bo wtedy robienie kwiatków będzie bardzo utrudnione i od razu będzie wiadomo kto jest odpowiedzialny). A robienie kwiatków w tych wyborach i poprzednich i jeszcze poprzednich jest pewne (mapki prof. Śleszyńskiego) i tu [do PE]. I teraz, miłościwie nam panujący, dostali do ręki świetny argument. I nikt nie będzie się sprzeciwiał, że głosy znów liczone są ręcznie - bo przecież mamy przykłady z przeszłości.

Zakończenie

Pozostaje się tylko zastanawiać, dlaczego KBW postawiła na swoje serwery (kosztowne rozwiązanie) zamiast sięgnąć po chmurę, która wręcz idealnie się do tego nadaje: ma olbrzymią przepustowość, skalowalność, a koszty w takim rozwiązaniu są znikome (w OVH można np. zapłacić za wykorzystany czas procesora). Powiedziałbym nawet, że o rząd wielkości mniejsze niż utrzymywanie własnej infrastruktury. Bowiem utrzymywać własną infrastrukturę musimy nawet wtedy, kiedy nie jest używana, chmurę wykupujemy kiedy chcemy. I to jest właśnie ta drobna różnica, którą prywaciarz by rozważył i wykorzystał, Państwo wydaje jednak nie swoje pieniądze na nie swoje potrzeby - prawie zawsze więc kupi za drogo i nie to co trzeba. I tym lekkim akcentem zakończę ten nieco przydługi artykuł. Dziękuję za wytrwałość!

12345
Myślenie stadne, a sprawa słynnego Kalkulatora Wyborczego Autor opinii: Czytelnicy, data przesłania: 5

Podobne artykuly:

Skomentuj

Aby zamieścić komentarz, proszę włączyć JavaScript - niestety roboty spamujące dają mi niezmiernie popalić.






Komentarze czytelników

    • HecSec
    • wto, 9 grudzień 2014, 13:19
    • Moj komentarz dotyczy raczej sfery użytkowej eksperckiej! Jest takie powiedzenie ...nie potrafisz nie pchaj się na afisz! Bezwzględnie w biznesie nie ma czasu na sentymenty a szczególnie gdy mowa o tak wielkim wyzwaniu! Przykro mi to mówić ale dobrymi chęciami jest wybrukowana droga do pieklą i tam się znaleźliśmy! Panowie z PKW kaskę i tak zwinęli i nikt ich nie ruszy wszak to emeryci prawie!
    • nusch
    • nie, 7 grudzień 2014, 1:18
    • Podstawowym błędem Nabino było podejście do przetargu którego żadna firma nie jest w stanie z odpowiednią jakością zrealizować w czasie jaki był dostępny. Brak ofert w przetargu spowodował by aferę wcześniej.
      Pozatym państwowe wybory na zagranicznym OVH? Gdzie ty żyjesz? Oszczędność nie jest w takim wypadkach rozwiązaniem, Państwo nie powinno za wybory przepłacać, ale też nigdy nie powinno wybierać pomiędzy cena a jakością.
    • Ktoś
    • sob, 6 grudzień 2014, 9:41
    • Bardzo fajny artykuł. Depesza pap z 2014-11-14 16:43 jest przekłamana. Testy nie były samymi testami obciążeniowymi, ale też testami oprogramowania jako takiego. Błędów wtedy było co mie miara po stronie samego oprogramowania, oprócz samych problemów komunikacyjnych. Co do chmury to odpowiedź jest prosta. Był niedawno zarzut o "rosyjskie" serwery. W przypadku chmury nie można takiej opcji wykluczyć, tym bardziej że nie ma żadnej możliwości wykluczenia z przetargów firm z rosyjskim kapitałem. KBW chciało się zabezpieczyć przed takimi zarzutami. Niestety wyszło jak wyszło. Zabrakło specjalistów.
    • romeczek
    • pią, 5 grudzień 2014, 11:06
    • po cholere bylo tworzyc caly system od poczatku jak mozna bylo kupic licencje na np Splunk i odpowiednio skonfigurowac (podejrzewam ze byloby taniej) ? W pracy (firma z branzy telekomunikacyjnej) przerabiamy ok 100GB logow i SNMP dziennie z pelna wizualizacja bez zadnych problemow. Nie sadze, zeby ilosc danych z tych wyborow byla az tak duza. Przy odpowiedniej konfiguracji wyniki przy wykorzystaniu Splunk (lub innych narzedzi do tzw Big Data) bylyby prawdopodnie znane w ciagu paru godzin o ile nie minut od zakonczenia. Chyba, ze komus szczegolnie zalezalo na tym, zeby zrobic taki cyrk jaki ma miejsce obecnie.
    • Cali
    • pią, 5 grudzień 2014, 10:04
    • Z tego co sie orientuje instytucje panstwowe nie moga korzystac z serwerow ktore nie znajduja sie w polsce, skad wiesz gdzie ta cala chmura sie znajduje.
    • Wiedzący
    • wto, 2 grudzień 2014, 20:19
    • @philips. Nawet ewentualna ingerencja w system informatyczy nie powinna doprowadzić do niewykrytego fałszerstwa wyborczego. A to z jednej i istotnej przyczyny. Od 2005 roku wszystkie dane na których operuje PKW oraz pomniejsze komisje wyborcze są dostępne on-line. Policzenie wszystkiego na "piechotę" może zająć pojedyneczej osobie nawet kilka lat, ale jest wykonalne. Jak na razie nikt nie wskazał tam błędu. Tylko dodatkowym warunkiem jest to, aby członkowie komisji oraz wyborcy sprawdzali czy umieszczone tam dane z protokołów są zgodne ze stanem faktycznym. Polecam każdemu wyborcy dbanie o to. Przykładowy protokół: http://wybory2014.pkw.gov.pl/pl/wyniki/protokoly/20684/42100


      Sam kiedyś myślałem nad stworzeniem bazy danych i programu, który pobierał by te informacje ze stron PKW lub lepiej w jakiejś zbiorczej formie, aby później poddać je weryfikacji obliczeniowej, ale darmo to mi się nie chce nad tym popracować. Jak mi Komitet Ochrony Wyborów, który zorganizował w tym roku PiS, zapłaci to się tym chętnie zajmę. I nie wezmę za to pół miliona złotych, gdyż system nie będzie tak rozbudowany i nie będę organizował szkolenia i uroczystej kolacji. Jak macie tam kontakty to siebie polecam.
    • Wiedzący
    • wto, 2 grudzień 2014, 20:09
    • Co do teorii spiskowej to pewnie ciebie nie przekonam, ale przy twoim analitycznym umyśle powinieneć być w stanie stwierdzić, w którym momencie miało by dojść do ewentualnego fałszerstwa (OKW, MKW, WKW)? Ma to znaczenie, gdyż wtedy pozwoliło by ustalić winnych. Jeżeli chodzi o korelacje wygranej PO w okręgach gdzie była większa ilość nieważnych głosów to jest dość łatwe wyjaśnienie. Tam ludzie nie głosują tak chętnie na PiS widząć ich zamiłowanie do teorii spiskowych zamiast myśleć o przyszłości, a ci którzy są sflustrowani to właśnie oddają głos nieważny a nie na partię miłości i uwielbienia ludu bożego. Co prawda bardzo mnie zaskoczyła analiza wykonana rzekomo przez prof. z PAN, ale jeszcze musiałbym sprawdzić, czy rzeczywiście oparł się o na danych do których twierdzi, że miał dostęp o rodzaju nieważnych głosów. Tylko pytanie czemu ewentualne fałszerstwo miało by dotyczyć tylko województwa Mazowieckiego?
    • Wiedzący
    • wto, 2 grudzień 2014, 20:00
    • Bardzo słuszne spostrzeżenia o potrzebie posiadania odpowiedniej wiedzy, aby wypowiadać się na temat możliwości manipulacji systemem wyborczym w PKW opratym na kryptografii infrastruktury klucza publicznego i prywatnego. Jak słyszałem o informatykach, którzy ekscytują się możliwością wygenerowania własnego certyfikatu i umieszczeniu podpisanego przez nich protokołu w systemie PKW, który wg nich miałby zostać uznany za ważny, to nie wiedziałem czy się śmiać czy płakać. Za to wypowiedzi polityków o tym, że byle student informatyki mógł sfałszować wybory to już tylko budziły we mnie złość, gdyż akurat ci nie znają się ani na informatyce ani na kryptografii.
    • philips
    • pon, 1 grudzień 2014, 22:01
    • Bardzo rzetelna analiza. Dodałbym tylko, że mnie razi nie tylko sam przetarg i wykonanie systemu, ale sposób dystrybucji kluczy prywatnych, zasad ich przechowywania. To samo dotyczy dostępu do maszyn na, których instalowane było oprogramowanie i ich specyfikacji. Myślę, że nie trzeba być geniuszem żeby włamać się na systemy z których wysyłane były protokoły, wgrać zmodyfikowaną wersję liczydła, przechwycić klucz prywatny i hasło.

      Osobiście straciłem zaufanie do wyborów w tym kraju.

      Nie bronił bym tak Nabino, z ich portfolio wynika, że sa blisko administracji. Podejrzewam, że stanęli do przetargu nie jako jedyni wybawcy, tylko odpowiednio wcześniej o nim wiedzieli i byli do niego przygotowani.
Dexter