Informatyka a oszustwa wyborcze.

Wpis odnośnie oszustwa w wyborach porusza ciekawe kwestie. Co prawda całość jest typu tl;dr, momentami autor nieźle odrywa się od rzeczywistości, teza wybory były sfałszowane i trzeba je powtórzyć jest totalnie niedorzeczna i całość mocno śmierdzi spiskową teorią dziejów, ale podstawowe spostrzeżenie jest celne: coraz większa część obliczeń – także tych wyborczych – realizowana jest na systemach komputerowych, a regulacji prawnych w tym zakresie nie ma.

Mamy więc – jak autor trafnie spostrzega – sytuację, gdzie urna w Pcimiu Dolnym jest nadzorowana w sposób przezroczysty dla wszystkich, stosunkowo łatwo weryfikowalny i dokładnie opisany przepisami prawa, ale przesyłanie i obliczanie danych z wszystkich komisji odbywa się w sposób pozwalający – przy odrobinie złej woli – na manipulację wynikami. I to manipulacje, które nie będą proste do wykrycia. A przecież zdobycie władzy, niekoniecznie w uczciwy sposób, zawsze jest i będzie kuszące.

Po pierwsze, do przekłamania może dojść przez przejęcie kontroli nad systemami, z których wprowadzane są dane. Trudno wykonalne (wiele systemów), łatwo wykrywalne. Po drugie, dane mogą być zamienione podczas transmisji. Wierzę, że wysyłane są połączeniem szyfrowanym i z użyciem algorytmów nie pozwalających na prostą podmianę. Czyli ten sposoby ataku raczej odpadają. Zostaje trzeci, czyli atak na centralne miejsce, które dokonuje obliczeń.

I tu nic nie da obecność członka komisji w serwerowni. OK, wyeliminuje to przepięcie kabelków, wyjęcie dysków (WTF?) i inne fizyczne ingerencje, ale nadal nie zapobiegnie podmianie danych na maszynie czy to na skutek zmian w programie (na różnych etapach – od tworzenia do kompilacji), czy na skutek modyfikacji danych w bazie, czy na zmodyfikowanie działania systemu na niższym poziomie.

W przeciwieństwie do autora, nie uważam, że konieczne jest odejście od obecnego, tradycyjnego systemu głosowania. Przede wszystkim dlatego, że głosowanie elektroniczne – choć możliwe, że tańsze – nigdy nie będzie tak przezroczyste dla laików komputerowych, jak tradycyjne. Będą też problemy z zachowaniem anonimowości głosów, jeśli głosy mają być bezpieczne. No i będzie trudno o łatwo weryfikowalne dowody, jeśli będziemy chcieli sprawdzić coś po głosowaniu.

Natomiast w obecnym systemie łatwo można – przy minimum nakładu pracy ze strony społeczeństwa – zapewnić kontrolę nad brakiem przekłamań. Dane z poszczególnych komisji są publikowane na stronach PKW. Każdy więc może samodzielnie zweryfikować, czy sumowanie jest dokonane prawidłowo (czy to ręcznie, czy w wybranym, choćby opensource’owym arkuszu kalkulacyjnym). To wyklucza podmiany wyników działania programu w centralnym miejscu.

Jeśli chodzi o przekłamania w transmisji czy podczas wprowadzania, również łatwo można to zweryfikować. Wystarczy się przejść do komisji dzień po wyborach. Wywieszane są ręcznie pisane protokoły. Wystarczy porównać dane ze strony PKW z danymi z protokołu. Jeśli się zgadzają – do oszustwa nie doszło, przynajmniej nie do oszustwa w systemie informatycznym i przy przesyłaniu danych. Przy powtórzeniu sprawdzenia dla wszystkich komisji (to wymaga współpracy społeczeństwa, pojedyncza osoba jest w stanie sprawdzić góra kilka-kilkanaście komisji) i nie znalezieniu rozbieżności mamy pewność, że wybory nie są sfałszowane.

A czy wy sprawdzacie pracę swojej komisji wyborczej?

Szybki rzut oka na polską chmurę czyli test e24cloud beta.

Jakiś czas temu serwis e24cloud, czyli polski hosting pod modnym szyldem chmury w wydaniu Beyond.pl, wszedł w fazę beta i publicznych testów, czyli praktycznie każdy chętny może – za darmo – pobawić się modną chmurą. Aktualnie firma rozdaje zaproszenia do testów o równowartości 200 zł, aby dostać kod należy postępować ze wskazówkami ze strony stwórz chmurę, czyli skorzystać z aplikacji na Facebooku.

Dłuższy wpis w trakcie tworzenia, a tymczasem szybki rzut oka na wady i zalety oferowanego testu (nie chciałbym, żeby było to traktowane jako test finalnej usługi, bo może się zmienić, poza tym parę kryteriów wybitnie testowych).

Wady:

  • brak IPv6 w domyślnej instalacji, brak możliwości wykupienia/wyklikania w panelu
  • przy pierwszym wyborze tylko 5 OS, w tym stary Debian (Lenny)
  • przy pierwszym wyborze konieczność wybrania 2 rdzeni
  • domyślne hasło roota tylko 8 znaków [a-zA-Z0-9]
  • 0,18 zł przy nieaktywnej (wstrzymanej) maszynie (2 CPU), 0,34 zł przy działającej
  • nie można dorzucić dodatkowych zasobów (CPU/RAM) do istniejącej maszyny
  • liczba CPU i RAM sztywno powiązane (każdy CPU to 2 GB RAM)
  • spora ilość błędów w panelu i słaba stabilność (nawet jak na wersję beta)
  • długi czas reakcji na zgłoszenie ticketa

Zalety:

  • maszyna szybko się generuje
  • wystarczający wybór presetów – siedem, w tym nowy Debian (Squeeze)
  • dostępny spory zakres sprzętu – 1-48 CPU i 2-96 RAM, dodatkowy HDD do 5 TB
  • 25 dni to wystarczający czas na przetestowanie
  • dobra wydajność (CPU)

Zabawa trwa, wkrótce można się spodziewać dłuższego i pełniejszego opisu testowanej usługi. Jeśli ktoś lubi się bawić, to pewnie warto skorzystać z darmowego testu, chociaż szału póki co nie ma.

UPDATE: W końcu otrzymałem odpowiedź na ticketa dotyczącego wyłączania się maszyny – wynika z błędu w panelu. Dodaję stosowny punkt, bo prawie 48h na prostą informację, że problem wynika z panelu to sporo. I usuwam niską stabilność usługi, bo wynika z błędów w panelu, nie w samej usłudze. Wiem, niby nieważne, czemu przestaje działać, ale jakoś wypada to oddzielić.

UPDATE: Widzę, że nadal jest trochę wejść z wyszukiwarek w poszukiwaniu informacji. Powyższe dane są stare i dotyczą wersji beta. Aktualna usługa jest zmieniona pod niektórymi względami. Aktualizacji danych lub nowego wpisu, chwilowo nie będzie, bo w tej chwili byłbym nieobiektywny.

Monitoring Tora w konsoli – howto.

Jak wiadomo m.in. z poprzedniego wpisu, prowadzę węzeł Tora. Bez połączeń wychodzących, czyli robię tylko za żuczka dokładającego jeden hop w ścieżce w celu zwiększenia anonimowości korzystających z tego programu. Od pewnego czasu miałem wrażenie, że jedyne, co robi mój Tor, to zajmuje pamięć (ponad 30% na biednym Dockstarze). Nie robiłem żadnych dokładnych statystyk, po prostu obserwowałem ilość ruchu na interfejsach, ale wyglądało, że jest mniej, niż kiedyś.

Postanowiłem sprawdzić, co się dzieje w rzeczywistości. Już kiedyś widziałem, że jest projekt arm czyli anonymizing relay monitor, ale wtedy nie było pakietów w Debianie, więc nie instalowałem, a pozwala on na znacznie więcej, niż tylko obejrzenie ilości ruchu, więc postanowiłem zainstalować arm.

W tej chwili paczka tor-arm jest dostępna w Debianie unstable (na stable instaluje się czysto), więc doinstalowałem ją (wajig install tor-arm). Samo uruchomienie (wpisanie arm) nic nie dało (używa domyślnej konfiguracji), więc po pierwsze, skopiowałem domyślną konfigurację (położenie w Debianie nieco inne niż podawane w manualu):

zcat /usr/share/doc/tor-arm/armrc.sample.gz > .arm/armrc

Nadal nic. Kolejna sprawa, to uruchomienie portu do kontroli w samym Torze, czyli dodanie w configu opcji:

ControlPort 9051

Po ponownym uruchomieniu arm jak najbardziej się połączył, ale ostrzega, że port do kontroli jest otwarty. Co prawda maszynka jest firewallowana, ale wypadałoby dodać hasło do zarządzania. Nie jest to trywialne i znalezienie zajęło mi dłuższą chwilę (chociaż jest w dokumentacji), więc opiszę. Najpierw generujemy hash hasła:

tor --hash-password jakieshaslo 

Otrzymujemy coś w stylu ciągu

16:2CCAAB2DEEB082CD60610B3BE6A0FF2A90EEFC92AD434C9C8CBFA42B0B

Następnie w konfiguracji Tora dodajemy linię

HashedControlPassword 16:2CCAAB2DEEB082CD60610B3BE6A0FF2A90EEFC92AD434C9C8CBFA42B0B

i restartujemy Tora (/etc/init.d/tor restart). Na koniec edytujemy ~.arm/armrc i uzupełniamy linię z startup.controlPassword, by miała postać:

startup.controlPassword jakieshaslo

Po zmianach okazało się, że miałem nosa i faktycznie niewiele się dzieje. Nawet bardzo niewiele. Praktycznie nic. Ponieważ kiedyś ruchu było więcej, postanowiłem sprawdzić, czy winnym nie jest ustawienie węzła jako bridge node. Bingo! Po zmianie od razu jest więcej ruchu. Zatem w chwili obecnej mój konfig Tora wygląda następująco:

ControlPort 9051
RelayBandwidthRate 20 KBytes
RelayBandwidthBurst 30 KBytes
ExitPolicy reject *:* # no exits allowed
ORPort 443
HashedControlPassword 16:2CCAAB2DEEB082CD60610B3BE6A0FF2A90EEFC92AD434C9C8CBFA42B0B

UPDATE: Przy okazji wygląda, że wyłączając tryb bridge node upiekłem dwie pieczenie na jednym ogniu. Po 16 godzinach zużycie pamięci RAM przez Tor wynosi ledwie 9%, zamiast wspomnianych 30%. Czyżby jakiś bug związany z trybem bridge? W każdym razie średni ruch upload i download teraz to po 50 Kbps, zużycie pamięci, które mnie trochę bolało mniejsze. Jednym słowem: lubię to! 😉