Tag Archives: Challenge

Human Longevity, Inc. – Changing Medicine Through Genomics Research

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/human-longevity-inc-changing-medicine-through-genomics-research/

Human Longevity, Inc. (HLI) is at the forefront of genomics research and wants to build the world’s largest database of human genomes along with related phenotype and clinical data, all in support of preventive healthcare. In today’s guest post, Yaron Turpaz,  Bryan Coon, and Ashley Van Zeeland, talk about how they are using AWS to store the massive amount of data that is being generated as part of this effort to revolutionize medicine.

Jeff;


When Human Longevity, Inc. launched in 2013, our founders recognized the challenges that lie ahead. A genome contains all the information needed to build and maintain an organism; in humans, a copy of the entire genome, which contains more than three billion DNA base pairs, is contained in all cells that have a nucleus. Our goal is to sequence one million genomes and deliver that information—along with integrated health records and disease-risk models—to researchers and physicians. They, in turn, can interpret the data to provide targeted, personalized health plans and identify the optimal treatment for cancer and other serious health risks far earlier than has been possible in the past. The intent is to transform medicine by fostering preventive healthcare and risk prevention in place of the traditional “sick care” model, when people wind up seeing their doctors only after symptoms manifest.

Our work in developing and applying large-scale computing and machine learning to genomics research entails the collection, analysis, and storage of immense amounts of data from DNA-sequencing technology provided by companies like Illumina. Raw data from a single genome consumes about 100 gigabytes; that number increases as we align the genomic information with annotation and phenotype sources and analyze it for health insights.

From the beginning, we knew our choice of compute and storage technology would have a direct impact on the success of the company. Using the cloud was clearly the best option. We’re experts in genomics, and don’t want to spend resources building and maintaining an IT infrastructure. We chose to go all in on AWS for the breadth of the platform, the critical scalability we need, and the expertise AWS has developed in big data. We also saw that the pace of innovation at AWS—and its deliberate strategy of keeping costs as low as possible for customers—would be critical in enabling our vision.

Leveraging the Range of AWS Services

 Spectral karyotype analysis / Image courtesy of Human Longevity, Inc.

Spectral karyotype analysis / Image courtesy of Human Longevity, Inc.

Today, we’re using a broad range of AWS services for all kinds of compute and storage tasks. For example, the HLI Knowledgebase leverages a distributed system infrastructure comprised of Amazon S3 storage and a large number of Amazon EC2 nodes. This helps us achieve resource isolation, scalability, speed of provisioning, and near real-time response time for our petabyte-scale database queries and dynamic cohort builder. The flexibility of AWS services makes it possible for our customized Amazon Machine Images and pre-built, BTRFS-partitioned Amazon EBS volumes to achieve turn-up time in seconds instead of minutes. We use Amazon EMR for executing Spark queries against our data lake at the scale we need. AWS Lambda is a fantastic tool for hooking into Amazon S3 events and communicating with apps, allowing us to simply drop in code with the business logic already taken care of. We use Auto Scaling based on demand, and AWS OpsWorks for managing a Docker pipeline.

We also leverage the cost controls provided by Amazon EC2 Spot and Reserved Instance types. When we first started, we used on-demand instances, but the costs started to grow significantly. With Spot and Reserved Instances, we can allocate compute resources based on specific needs and workflows. The flexibility of AWS services enables us to make extensive use of dockerized containers through the resource-management services provided by Apache Mesos. Hundreds of dynamic Amazon EC2 nodes in both our persistent and spot abstraction layers are dynamically adjusted to scale up or down based on usage demand and the latest AWS pricing information. We achieve substantial savings by sharing this dynamically scaled compute cluster with our Knowledgebase service and the internal genomic and oncology computation pipelines. This flexibility gives us the compute power we need while keeping costs down. We estimate these choices have helped us reduce our compute costs by up to 50 percent from the on-demand model.

We’ve also worked with AWS Professional Services to address a particularly hard data-storage challenge. We have genomics data in hundreds of Amazon S3 buckets, many of them in the petabyte range and containing billions of objects. Within these collections are millions of objects that are unused, or used once or twice and never to be used again. It can be overwhelming to sift through these billions of objects in search of one in particular. It presents an additional challenge when trying to identify what files or file types are candidates for the Amazon S3-Infrequent Access storage class. Professional Services helped us with a solution for indexing Amazon S3 objects that saves us time and money.

Moving Faster at Lower Cost
Our decision to use AWS came at the right time, occurring at the inflection point of two significant technologies: gene sequencing and cloud computing. Not long ago, it took a full year and cost about $100 million to sequence a single genome. Today we can sequence a genome in about three days for a few thousand dollars. This dramatic improvement in speed and lower cost, along with rapidly advancing visualization and analytics tools, allows us to collect and analyze vast amounts of data in close to real time. Users can take that data and test a hypothesis on a disease in a matter of days or hours, compared to months or years. That ultimately benefits patients.

Our business includes HLI Health Nucleus, a genomics-powered clinical research program that uses whole-genome sequence analysis, advanced clinical imaging, machine learning, and curated personal health information to deliver the most complete picture of individual health. We believe this will dramatically enhance the practice of medicine as physicians identify, treat, and prevent diseases, allowing their patients to live longer, healthier lives.

Learn More
Learn more about how AWS supports genomics in the cloud, and see how genomics innovator Illumina uses AWS for accelerated, cost-effective gene sequencing.

Yaron Turpaz (Chief Information Officer), Bryan Coon (Head of Enterprise Services), and Ashley Van Zeeland (Chief Technology Officer).

Physical therapy with a pressure-sensing football

Post Syndicated from Alex Bate original https://www.raspberrypi.org/blog/physical-therapy-pressure-sensing-football/

Every year, eighth-grade science teacher Michele Chamberlain challenges her students to find a solution to a real-world problem. The solution must be environmentally friendly, and must demonstrate their sense of global awareness.

Amelia Day

Amelia with her project.

One of Michele’s students, 14-year-old Amelia Day, knew she wanted to create something that would help her practice her favourite sport, and approached Chamberlain with an idea for a football-related project.

I know you said to choose a project you love,” Amelia explained, “I love soccer and I want to do something with engineering. I know I want to compete.”

Originally, the tool was built to help budding football players practise how to kick a ball correctly. The ball, tethered to a parasol shaft, uses a Raspberry Pi, LEDs, Bluetooth, and pressure points; together, these help athletes to connect with the ball with the right degree of force at the appropriate spot.

However, after a conversation with her teacher, it became apparent that Amelia’s ball could be used for so much more. As a result, the project was gradually redirected towards working with stroke therapy patients.

“It uses the aspect of a soccer training tool and that interface makes it fun, but it also uses Bluetooth audio feedback to rebuild the neural pathways inside the brain, and this is what is needed to recover from a stroke,” explains Amelia. 

“DE3MYSC Submission – [Press-Sure Soccer Ball]”

Uploaded by Amelia Day on 2016-04-20.

The video above comes as part of Amelia’s submission for the Discover Education’s 3M ‘Young Science Challenge 2016’, a national competition for fifth- to eight-grade students from across the USA.

Down to the last ten finalists, Amelia travelled to 3M HQ in Minnesota this October where she had to present her project to a panel of judges. She placed third runner up and received a cash prize.

LMS Hawks on Twitter

Our very own Amelia Day placed 3rd runner up @ the 3M National Junior Scientist competition this week. Proud to call her a Hawk!📓✏️🔎⚽️ #LMS

We’re always so proud to see young makers working to change the world and we wish Amelia the best of luck with her future. We expect to see great things from this Lakeridge Middle School Hawk.

The post Physical therapy with a pressure-sensing football appeared first on Raspberry Pi.

Comments for my biracial niece

Post Syndicated from Robert Graham original http://blog.erratasec.com/2016/11/comments-for-my-biracial-niece.html

I spent the night after Trump’s victory consoling my biracial niece worried about the election. Here are my comments. You won’t like them, expecting the opposite given the title. But it’s what I said.

I preferred Hillary, but that doesn’t mean Trump is an evil choice.
Don’t give into the hate. You get most of your news via social media sites like Facebook and Twitter, which are at best one-sided and unfair. At worst, they are completely inaccurate. Social media posts are driven by emotion, not logic. Sometimes that emotion is love of cute puppies. Mostly it’s anger, fear, and hate. Instead of blindly accepting what you read, challenge it. Find the original source. Find a better explanation. Search for context.
Don’t give into the hate. The political issues that you are most concerned about are not simple and one-sided with obvious answers. They are complex and nuanced. Just because somebody disagrees with you doesn’t mean they are unreasonable or evil. In today’s politics, it has become the norm that we can’t simply disagree with somebody, but must also vilify and hate them. We’ve redefined politics to be the fight between the virtuous (whatever side we are on) and the villains (the other side). The reality is that both sides are equally reasonable, equally virtuous.
Don’t give into the hate. Learn “critical thinking”. Learn how “cherry picking” the fringe of the opposing side is used to tarnish the mainstream. Learn how “strawman arguments” makes the other side sound dumb. Learn how “appeal to emotion” replaces logic. Learn how “ad hominem” statements attack the credibility of opponent’s arguments. Learn how issues are simplified into “black vs. white” options rather than the nuance and complexity that actually exists.
Don’t give into the hate. The easy argument is that it’s okay to be hateful and bigoted toward Trump and his supporters because they are bigoted against you. No, it’s not okay to hate anybody, not even Hitler, as Atticus Finch explains in “To Kill A Mockingbird”. In that book, Atticus even tries to understand, and not hate, Robert Ewell, the racist antagonist in the book who eventually tries to stab Scout (Atticus’s daughter). Trump’s supporters may be wrong, but it’s a wrongness largely based on ignorance, not malice. Yes, they probably need to be kindly educated, but they don’t deserve punishment and hate.

America is the same country it was last week. It’s citizens haven’t changed, only one man in an office has changed. The President has little actual power, either to fix things (as his supporters want) or to break things (as his opponents fear). We have strong institutions, from Congress, to the Courts, to the military, that will hold him check. The biggest worries are that he’s the first President in history with no government experience, and that he’s strongly “populist” (which historically has been damaging for countries). We should be watchful, and more willing to stand up and fight when Trump does something bad. However, we shouldn’t give into hate.

Topics in live kernel patching

Post Syndicated from corbet original http://lwn.net/Articles/706327/rss

Getting live-patching capabilities into the mainline kernel has been a
multi-year process. Basic patching support was merged for the 4.0 release,
but further work has been stalled over
disagreements on how the consistency model — the code ensuring that a patch
is safe to apply to a running kernel — should work. The addition of kernel stack validation has addressed the
biggest of the objections, so, arguably, it is time to move forward. At
the 2016 Linux Plumbers
Conference
, developers working on live patching got together to discuss
current challenges and future directions.

Click below (subscribers only) for the full report from LPC 2016.

[$] Topics in live kernel patching

Post Syndicated from corbet original http://lwn.net/Articles/706327/rss

Getting live-patching capabilities into the mainline kernel has been a
multi-year process. Basic patching support was merged for the 4.0 release,
but further work has been stalled over
disagreements on how the consistency model — the code ensuring that a patch
is safe to apply to a running kernel — should work. The addition of kernel stack validation has addressed the
biggest of the objections, so, arguably, it is time to move forward. At
the 2016 Linux Plumbers
Conference
, developers working on live patching got together to discuss
current challenges and future directions.

Click below (subscribers only) for the full report from LPC 2016.

University of York Raspberry Pi Challenge 2016

Post Syndicated from Alex Bate original https://www.raspberrypi.org/blog/university-york-raspberry-pi-challenge-2016/

The Department of Computer Science at the University of York holds a Raspberry Pi Challenge every year with the intention of introducing future students to the world of programming, regardless of their prior experience. They aim to create a wide community of support for all in much the same way as the Raspberry Pi Foundation does, working to introduce their students to each other and helping to build relationships before the start of the academic year.

Gordon Hollingworth, our Director of Software Engineering, visited the department as one of the judges of this year’s competition… sorry, he’s just advised me that he was Head Judge, and he’s now saying something about bicycles… and provided his wealth of knowledge and experience. He also provided a lot of stickers.

For information on the event, plus examples of some of the brilliant projects created by the students, check out the video below.

University of York Computer Science ‘Raspberry Pi Challenge’ 2016

The University of York’s Department of Computer Science ‘Raspberry Pi Challenge’ 2016

 

The post University of York Raspberry Pi Challenge 2016 appeared first on Raspberry Pi.

Squarespace OCSP Stapling Implementation

Post Syndicated from Let's Encrypt - Free SSL/TLS Certificates original https://letsencrypt.org/2016/10/24/squarespace-ocsp-impl.html

<blockquote>
<p>We’re excited that Squarespace has decided to protect the millions of sites they host with HTTPS! While talking with their
team we learned they were deploying OCSP Stapling from the get-go, and we were impressed. We asked them to share their
experience with our readers in our first guest blog post (hopefully more to come).</p>

<p>- Josh Aas, Executive Director, ISRG / Let’s Encrypt</p>
</blockquote>

<p><a href="https://en.wikipedia.org/wiki/OCSP_stapling">OCSP stapling</a> is an alternative approach to the Online Certificate Status Protocol (OCSP) for checking the revocation status of certificates. It allows the presenter of a certificate to bear the resource cost involved in providing OCSP responses by appending (“stapling”) a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA. The certificate holder queries the OCSP responder at regular intervals and caches the responses.</p>

<p>Traditional OCSP requires the CA to provide responses to each client that requests certificate revocation information. When a certificate is issued for a popular website, a large amount of queries start hitting the CA’s OCSP responder server. This poses a privacy risk because information must pass through a third party and the third party is able to determine who browsed which site at what time. It can also create performance problems, since most browsers will contact the OCSP responder before loading anything on the web page. OCSP stapling is efficient because the user doesn’t have to make a separate connection to the CA, and it’s safe because the OCSP response is digitally signed so it cannot be modified without detection.</p>

<h2 id="ocsp-stapling-squarespace">OCSP Stapling @ Squarespace</h2>

<p>As we were planning our roll out of SSL for all custom domains on the Squarespace platform, we decided that we wanted to support OCSP stapling at time of launch. A reverse proxy built by our <a href="https://www.squarespace.com/about/careers?gh_jid=245517">Edge Infrastructure team</a> is responsible for terminating all SSL traffic, it’s written in Java and is powered by <a href="http://netty.io/">Netty</a>. Unfortunately, the Java JDK 8 only has preliminary, client-only, OCSP stapling support. JDK 9 introduces OCSP stapling with <a href="http://openjdk.java.net/jeps/249">JEP 249</a>, but it is not available yet.</p>

<p>Our reverse proxy does not use the JDK’s SSL implementation. Instead, we use OpenSSL via <a href="http://netty.io/wiki/forked-tomcat-native.html">netty-tcnative</a>. At this time, neither the original tcnative nor Netty’s fork have OCSP stapling support. However, the tcnative library exposes the inner workings of OpenSSL, including the address pointers for the SSL context and engine. We were able to use JNI to extend the netty-tcnative library and add OCSP stapling support using the <a href="https://www.openssl.org/docs/man1.0.2/ssl/SSL_set_tlsext_status_type.html">tlsext_status</a> OpenSSL C functions. Our extension is a standalone library but we could equally well fold it into the netty-tcnative library itself. If there is interest, we can contribute it upstream as part of Netty’s next API-breaking development cycle.</p>

<p>One of the goals of our initial OCSP stapling implementation was to take the biggest edge off of the OCSP responder’s operator, in this case Let’s Encrypt. Due to the nature of the website traffic on our platform, we have a very long tail. At least to start, we don’t pre-fetch and cache all OCSP responses. We decided to fetch OCSP responses asynchronously and we try to do it only if more than one client is going to use it in the foreseeable future. Bloom filters are utilized to identify “one-hit wonders” that are not worthy of being cached.</p>

<p>Squarespace invests in the security of our customers’ websites and their visitors. We will continue to make refinements to our OCSP stapling implementation to eventually have OCSP staples on all requests. For a more in depth discussion about the security challenges of traditional OCSP, we recommend <a href="https://www.imperialviolet.org/2014/04/19/revchecking.html">this blog post</a>.</p>

The importance of paying attention in building community trust

Post Syndicated from Matthew Garrett original https://mjg59.dreamwidth.org/44915.html

Trust is important in any kind of interpersonal relationship. It’s inevitable that there will be cases where something you do will irritate or upset others, even if only to a small degree. Handling small cases well helps build trust that you will do the right thing in more significant cases, whereas ignoring things that seem fairly insignificant (or saying that you’ll do something about them and then failing to do so) suggests that you’ll also fail when there’s a major problem. Getting the small details right is a major part of creating the impression that you’ll deal with significant challenges in a responsible and considerate way.

This isn’t limited to individual relationships. Something that distinguishes good customer service from bad customer service is getting the details right. There are many industries where significant failures happen infrequently, but minor ones happen a lot. Would you prefer to give your business to a company that handles those small details well (even if they’re not overly annoying) or one that just tells you to deal with them?

And the same is true of software communities. A strong and considerate response to minor bug reports makes it more likely that users will be patient with you when dealing with significant ones. Handling small patch contributions quickly makes it more likely that a submitter will be willing to do the work of making more significant contributions. These things are well understood, and most successful projects have actively worked to reduce barriers to entry and to be responsive to user requests in order to encourage participation and foster a feeling that they care.

But what’s often ignored is that this applies to other aspects of communities as well. Failing to use inclusive language may not seem like a big thing in itself, but it leaves people with the feeling that you’re less likely to do anything about more egregious exclusionary behaviour. Allowing a baseline level of sexist humour gives the impression that you won’t act if there are blatant displays of misogyny. The more examples of these “insignificant” issues people see, the more likely they are to choose to spend their time somewhere else, somewhere they can have faith that major issues will be handled appropriately.

There’s a more insidious aspect to this. Sometimes we can believe that we are handling minor issues appropriately, that we’re acting in a way that handles people’s concerns, while actually failing to do so. If someone raises a concern about an aspect of the community, it’s important to discuss solutions with them. Putting effort into “solving” a problem without ensuring that the solution has the desired outcome is not only a waste of time, it alienates those affected even more – they’re now not only left with the feeling that they can’t trust you to respond appropriately, but that you will actively ignore their feelings in the process.

It’s not always possible to satisfy everybody’s concerns. Sometimes you’ll be left in situations where you have conflicting requests. In that case the best thing you can do is to explain the conflict and why you’ve made the choice you have, and demonstrate that you took this issue seriously rather than ignoring it. Depending on the issue, you may still alienate some number of participants, but it’ll be fewer than if you just pretend that it’s not actually a problem.

One warning, though: while building trust in this way enhances people’s willingness to join your community, it also builds expectations. If a significant issue does arise, and if you fail to handle it well, you’ll burn a lot of that trust in the process. The fact that you’ve built that trust in the first place may be what saves your community from disintegrating completely, but people will feel even more betrayed if you don’t actively work to rebuild it. And if there’s a pattern of mishandling major problems, no amount of getting the details right will matter.

Communities that ignore these issues are, long term, likely to end up weaker than communities that pay attention to them. Making sure you get this right in the first place, and setting expectations that you will pay attention to your contributors, is a vital part of building a meaningful relationship between your community and its members.

comment count unavailable comments

AWS discount vouchers? We can do better than that!

Post Syndicated from Brian Huang original https://www.anchor.com.au/blog/2016/07/aws-discount-voucher/

If you’re looking to reduce your AWS spend, read on.

It’s no secret that the range of cloud services offered by providers such as Amazon Web Services brings many benefits to your business. Despite this, complex usage pricing and a huge range of services (around 60 at this stage!) means that it can be challenging controlling your costs.

While many organisations move to the cloud expecting to save money, depending on how you’ve set things up you may find you’re spending more than you expected to. And while AWS discount vouchers sadly aren’t really a thing – Anchor has a few simple ways to reduce your AWS costs.

You can get a quick fix with the “AWS Caretaker” service – simply link Anchor as your billing provider and you’ll immediately benefit from our volume discounts. We should be able to reduce your AWS spend by 5-10% almost overnight, plus you’ll enjoy the benefits of vastly improved monitoring and reporting and you’ll have Anchor’s AWS certified technical support teams at your beck and call 24×7. With friendly month-to-month contracts, it’s a no brainer.

Alternatively, Anchor’s AWS Cost Savings Reporting Engine (available to our AWS Cloud Ops customers) provides deep visibility into your AWS environment usage, unearthing further opportunities to save money – up to 40% on your AWS bills. Our optimisation engine can recommend RI purchases for each instance type, OS and availability zone, the upfront cost of those purchases, and the estimated savings that will result from those purchases if you maintain your usage patterns.

aws cost modesl

Under normal circumstances, Amazon Web Services’ complex, usage-based pricing system makes it hard to control your costs. A read through “How AWS Pricing Works“, a quick scroll down Amazon’s EC2 pricing page or a minute or two with the “AWS Simple Monthly Calculator” tells the story.

You need to immerse yourself in the world of Reserved Instances (RIs); carefully considering your EC2 instance families and commit to a 1 or 3 year term while deciding whether you want to pay everything upfront, make a partial upfront payment or continue to pay as you go on a monthly basis.

Comparing breakeven points and exploring the differences between All-Upfront and Partial-Upfront Reservations while taking into account existing Reservations you’ve purchased in the context of your current deployment is a huge challenge – especially from a spreadsheet.

It can take hours (days!) to calculate how many reservations you need – and if you buy the wrong quantity or types of Reserved Instances, you could end up spending more money than you save.

While there is quite clearly some work to do and risks to consider, the savings you make can be significant:

AWS RIs

Get in touch with our team if you’d like to understand how Anchor can help reduce your costs. A quick review of your AWS account and we’ll be able to give you an estimate of the savings we can deliver (and added value we can provide!) in no time.

Get in touch and reduce your next AWS invoice!

The post AWS discount vouchers? We can do better than that! appeared first on AWS Managed Services by Anchor.

I’ve bought some more awful IoT stuff

Post Syndicated from Matthew Garrett original https://mjg59.dreamwidth.org/43486.html

I bought some awful WiFi lightbulbs a few months ago. The short version: they introduced terrible vulnerabilities on your network, they violated the GPL and they were also just bad at being lightbulbs. Since then I’ve bought some other Internet of Things devices, and since people seem to have a bizarre level of fascination with figuring out just what kind of fractal of poor design choices these things frequently embody, I thought I’d oblige.

Today we’re going to be talking about the KanKun SP3, a plug that’s been around for a while. The idea here is pretty simple – there’s lots of devices that you’d like to be able to turn on and off in a programmatic way, and rather than rewiring them the simplest thing to do is just to insert a control device in between the wall and the device andn ow you can turn your foot bath on and off from your phone. Most vendors go further and also allow you to program timers and even provide some sort of remote tunneling protocol so you can turn off your lights from the comfort of somebody else’s home.

The KanKun has all of these features and a bunch more, although when I say “features” I kind of mean the opposite. I plugged mine in and followed the install instructions. As is pretty typical, this took the form of the plug bringing up its own Wifi access point, the app on the phone connecting to it and sending configuration data, and the plug then using that data to join your network. Except it didn’t work. I connected to the plug’s network, gave it my SSID and password and waited. Nothing happened. No useful diagnostic data. Eventually I plugged my phone into my laptop and ran adb logcat, and the Android debug logs told me that the app was trying to modify a network that it hadn’t created. Apparently this isn’t permitted as of Android 6, but the app was handling this denial by just trying again. I deleted the network from the system settings, restarted the app, and this time the app created the network record and could modify it. It still didn’t work, but that’s because it let me give it a 5GHz network and it only has a 2.4GHz radio, so one reset later and I finally had it online.

The first thing I normally do to one of these things is run nmap with the -O argument, which gives you an indication of what OS it’s running. I didn’t really need to in this case, because if I just telnetted to port 22 I got a dropbear ssh banner. Googling turned up the root password (“p9z34c”) and I was logged into a lightly hacked (and fairly obsolete) OpenWRT environment.

It turns out that here’s a whole community of people playing with these plugs, and it’s common for people to install CGI scripts on them so they can turn them on and off via an API. At first this sounds somewhat confusing, because if the phone app can control the plug then there clearly is some kind of API, right? Well ha yeah ok that’s a great question and oh good lord do things start getting bad quickly at this point.

I’d grabbed the apk for the app and a copy of jadx, an incredibly useful piece of code that’s surprisingly good at turning compiled Android apps into something resembling Java source. I dug through that for a while before figuring out that before packets were being sent, they were being handed off to some sort of encryption code. I couldn’t find that in the app, but there was a native ARM library shipped with it. Running strings on that showed functions with names matching the calls in the Java code, so that made sense. There were also references to AES, which explained why when I ran tcpdump I only saw bizarre garbage packets.

But what was surprising was that most of these packets were substantially similar. There were a load that were identical other than a 16-byte chunk in the middle. That plus the fact that every payload length was a multiple of 16 bytes strongly indicated that AES was being used in ECB mode. In ECB mode each plaintext is split up into 16-byte chunks and encrypted with the same key. The same plaintext will always result in the same encrypted output. This implied that the packets were substantially similar and that the encryption key was static.

Some more digging showed that someone had figured out the encryption key last year, and that someone else had written some tools to control the plug without needing to modify it. The protocol is basically ascii and consists mostly of the MAC address of the target device, a password and a command. This is then encrypted and sent to the device’s IP address. The device then sends a challenge packet containing a random number. The app has to decrypt this, obtain the random number, create a response, encrypt that and send it before the command takes effect. This avoids the most obvious weakness around using ECB – since the same plaintext always encrypts to the same ciphertext, you could just watch encrypted packets go past and replay them to get the same effect, even if you didn’t have the encryption key. Using a random number in a challenge forces you to prove that you actually have the key.

At least, it would do if the numbers were actually random. It turns out that the plug is just calling rand(). Further, it turns out that it never calls srand(). This means that the plug will always generate the same sequence of challenges after a reboot, which means you can still carry out replay attacks if you can reboot the plug. Strong work.

But there was still the question of how the remote control works, since the code on github only worked locally. tcpdumping the traffic from the server and trying to decrypt it in the same way as local packets worked fine, and showed that the only difference was that the packet started “wan” rather than “lan”. The server decrypts the packet, looks at the MAC address, re-encrypts it and sends it over the tunnel to the plug that registered with that address.

That’s not really a great deal of authentication. The protocol permits a password, but the app doesn’t insist on it – some quick playing suggests that about 90% of these devices still use the default password. And the devices are all based on the same wifi module, so the MAC addresses are all in the same range. The process of sending status check packets to the server with every MAC address wouldn’t take that long and would tell you how many of these devices are out there. If they’re using the default password, that’s enough to have full control over them.

There’s some other failings. The github repo mentioned earlier includes a script that allows arbitrary command execution – the wifi configuration information is passed to the system() command, so leaving a semicolon in the middle of it will result in your own commands being executed. Thankfully this doesn’t seem to be true of the daemon that’s listening for the remote control packets, which seems to restrict its use of system() to data entirely under its control. But even if you change the default root password, anyone on your local network can get root on the plug. So that’s a thing. It also downloads firmware updates over http and doesn’t appear to check signatures on them, so there’s the potential for MITM attacks on the plug itself. The remote control server is on AWS unless your timezone is GMT+8, in which case it’s in China. Sorry, Western Australia.

It’s running Linux and includes Busybox and dnsmasq, so plenty of GPLed code. I emailed the manufacturer asking for a copy and got told that they wouldn’t give it to me, which is unsurprising but still disappointing.

The use of AES is still somewhat confusing, given the relatively small amount of security it provides. One thing I’ve wondered is whether it’s not actually intended to provide security at all. The remote servers need to accept connections from anywhere and funnel decent amounts of traffic around from phones to switches. If that weren’t restricted in any way, competitors would be able to use existing servers rather than setting up their own. Using AES at least provides a minor obstacle that might encourage them to set up their own server.

Overall: the hardware seems fine, the software is shoddy and the security is terrible. If you have one of these, set a strong password. There’s no rate-limiting on the server, so a weak password will be broken pretty quickly. It’s also infringing my copyright, so I’d recommend against it on that point alone.

comment count unavailable comments

Някои идеи за електронното гласуване

Post Syndicated from Delian Delchev original http://feedproxy.google.com/~r/delian/~3/3SzV7avcgtQ/blog-post_24.html

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


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


За мен технологичните дискусии на този етап са преждевременни. Те са еквивалентни на дискусиите – дайте да нямаме гласуване въобще, защото може да се подправя. По добре ли ще ни е с един неподправен цар или дикатура на партията? 🙂 Няма съществена разлика в тезите. И вероятно за това царските движения и почитатели на диктатурата на партии, са основните противници на електронното гласуване.


Това не значи, че бягам от обсъждане на технологии. Това ми е страст. В този текст, искам да опиша един процедурен модел, как може да бъде реализирано електронно гласуване сигурно и анонимно. Това не е предложение как да бъде реализирано. Нито твърдение, че ще бъде реализирано точно така. Това е само илюстрация, че може. Технологичната дискусия е въпрос за обсъждане след като бъде взето решение да има електронно гласуване. Там трябва да сме внимателни, за да няма издънки от държавата. Но същевременно, не можем да смятаме, че държавата цели или съществува само за да прави издънки, защото иначе какъв е смисъла от нея? Най добре да дойде друг цар и господар, който да ни управлява нали? Ах, да, рязясних още една от тезите на противниците 🙂


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


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


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


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


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


При присъственото гласуване, “личното” се гарантира типично чрез механизмите за аутентикация предвидени за личната карта. Ако снимката ти отговаря на личната карта, и ти имаш доверие на картата и издателят и, то ти приемаш (но няма абсолютна гаранция), че лицето е това, за което се представя и идва да гласува лично.


Тайната на вота се гарантира от безименни бюлетини и от гласуване в (макар и) обществена стая, такава в която трети страни твърдят, че е сигурно, че няма никой друг (но няма абсолютна гаранция).


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


Ние добре знаем обаче, че над 1 на 10000 лични карти са фалшифицирани.
Знаем, за мъртвите души – хора, които имат право да гласуват, и са в списъците за гласоподаватели, но са починали, и се използват за да се позволи да има останали свободни бюлетини добавяни в последният момент в урните, без това да създава подозрения при централното преброяване, тъй като броят на бюлетините е под или около очакваната бройка.
Само сега, за тези избори са премахнати над 500000 мъртви души (заради правилото за уседналост), но това не са всички, и ни дават чудесен индикатор колко неточни са всъщност изборните списъци. На по-предни избори бяха премахнати други 700000. Но постоянната урбанизация (при местните избори има изискване за уседналост), емиграция, динамика на смъртността, създават естествен процес на проява на мъртви души, тъй като списъците по места, физически няма как да са идеално актуални (макар централно да има как).

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

Нещо повече, на някой места местни картели от представители в ИК си добавят бюлетини в последният момент, и дори да са преброени много над подписалите се, че са гласували, тъй като няма как да се разбере, кои са истински и кои не са, се броят всички и участват в преброяването. Общо, грешките (невалидни, дублирани бюлетини, мъртви души) плават между 5 и 15% на изборите и обикновено нямат съществено значение по отношение на цялостният изборен резултат. Но имат съществено значение при преразпределението на локалните мандати и при местните избори, където често един мандат (заради фрагментацията) или кмет се избират с по малко от 5000 гласа. Тези грешки, както и ниската избирателна активност имат значение и за партиите, които влизат в парламента или получават субсидия. За пример, на предните парламентарни избори само 50000 гласа по голяма изборна активност (под 1% от всички имащи право на глас) деляха дали АБВ и АТАКА ще влязат в парламента или не. Даже, нямаше значение за кого са гласували тези хора, тъй като става въпрос за фрагментацията от разпределението на мандати. Само ниска избирателна активност. Дали това е една от причините и двете партии да са твърди противници на всякакви методики за повишаване на изборната активност (от реклами, през задължително гласуване, до против електронното гласуване, всъщност АБВ официално е за електронно гласуване, но негови представители се изказват публично против) не знам.

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


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


Нека да си представим обаче, следната хипотетична ситуация –


Че имаме разеделние между компонентите – лична оторизация, придобиване на право да гласуваш (бюлетина), асоциирането на бюлетина с вот (гласуване) и преброяване на гласовете. Всеки един от тези елементи се оторизира и проверява в отделна и независима организация, а нещо друго (например математиката?) ни гарантира съседна двустранна асоциация, но не и такава, която прескача съсед. Тогава много изкривявания (но не всички) на текущият модел биха били преодолени автоматично.


Обяснявам малко по детайлно – всичко това си го имаме и сега, но нека си представим че то е напълно отделено в отделни организации и процесите се случват независимо. Следните отделни и независими компоненти, мога да определя:


  1. Оторизация на едно място, че ти си си ти (еквивалент на издаване на личната карта) и получаване на съответният идентификатор за това (сега това е личната карта издадена от МВР, но може да бъде и електроне подпис или друго, от една организация)
  2. Оторизация, че имаш право да получиш бюлетина, с която да гласуваш (сега това го прави изборната комисия, проверяваща те в изборният списък и гарантираща, че ти си ти, чрез сертификата издаден от организация 1, в електронният можеш да получиш генериран математически случаен електронен сертификат, проверяем математически (може да е hash функция) и подписан със сертификата на тази втора организация, така че да е непроменим)
  3. Асоцииране на вот с бюлетина (сега го правиш пред изборната комисия, която подпечатва бюлетината ти, за да гарантира пред трети страни че е валидна, електронно може да е трета организация, например сайт, в който ти подписваш електронно избора си с полученият от 2 сертификат)
  4. Преброяване на бюлетините (прави го ЦИК, с под изпълнител типично ИО, в електронният свят това е преброяване и двойно валидиране на валидноста на електронната бюлетина, от четвърта организация)


Нека си представим преднатата система реализирана така (отново, технологията е примерна, не е важна, важна е процедурата и принципа) –
  1. Отиваш и си издаваш електронен подпис, който валидира, че ти си си ти. Той съдържа уникален твой сертификат валидиран от издателят на сертификата (всъщност днес това го правят всички клонове на банки, за 15 лева), което има това право (еквивалент на МВР). Електронният подпис е само пример. Може да бъде електронната ти идентификационна карта (личната ти карта, която ще можеш да получиш от 2017-та година нататък), може да е One-Time-Password система от друга форма. Няма голямо значение. Технологията не е важна, на този етап.
  2. Отиваш и получаваш електронна бюлетина срещу електронният си подпис, тя представлява да речем hash функционално число, подписано от твоят сертификат (но без идентификационна информация) или от алтернативен по-анонимен алгоритъм, като да речем модифициран DH (или уникален случаен частен ключ, и двете могат да дойдат пак през електронният ти подпис). Получената информация пък е подписана със сертификат от организацията издаваща електронните бюлетин (тук можем да правим вариации, може да имаш уникален публичен и частен ключ, генерирани случайно и дадени за теб например).
  3. Отиваш на сайта за гласуване, там с полученият частен ключ подписваш бюлетината и я пращаш обратно на сайта за гласуване, който я подписва със своят си сертификат (сертификатите играят роля на печатите при ИК) и предава веднага или по късно на организацията за преброяване (или пък я предава веднага на междинна организация, но тя я предава на организацията за преброяване след приключване на изборният ден).
  4. Организацията за преброяване получава всички сертификати. Тя има публичните ключове на (1), 2 и 3 (но не и частните). Като резултат тя може да чете информацията (но никой друг не може да чете освен своята си част) и да направи преброяване и пълна валидация. Отделно от 2 е получила списъка с генерираните хешове, има как да ги валидира математически (че са истински) и приема само тези сертификати, които съдържат коректен хеш.


Какъв е резултата от това разделение на отделни независими и несвързани организации:


Имаме невъзможност за генериране на фалшификати (подписванията при 2 и 3 стават локално при гласуващият, през мрежата пътуват и сайтовете получават само подписани сертификати), за да има фалшификат трябва някой да е компрометирал едновременно 1, 2 и 3 (което може да стане само при личният компютър на гласуващият, но дори той да е компрометиран, пак не може да стане лесно – опитайте се да подмените съдържанието на подписваната информация от електронният подпис в ръцете ви на собственият ви компютър. Ако успеете, ми се обадете).
Дори да приемем това за възможно при компютъра на гласуващият, то ще бъде невъзможно да бъде направено масово (няма как в ограничен период от време да повлияеш и да проконтролираш милиони компютри и милиони сертификати), което го прави по добре стоящо от сегашният модел (ЦИК публикува на всяко гласуване статистика показваща близо поне 100к невалидни или дублирани бюлетини, и то по доста консервативният механизъм на оценка, който имат). Също така, подмяната изисква интерактивно действие в момента, в който потребителят се оторизира. Ще ми бъде изключително интересно да чуя как може да стане при един масов електронен вот, в реално време, в рамките на изборният ден. Дори да имаме 1-2 случая на подмяна, те ще са много малко за да повлияят на резултата, и отделно точно електронното гласуване може да допусне механизъм как да се откриват и поправят.


Имаме и гаранция за тайна на вота. Защото само 1 знае дали имаш право да гласуваш и кой си ти. Само 2 издава бюлетина срещу информацията от 1 (но не е задължително да знае кой си, стига да знае, че имаш валиден сертификат, чиято валидация може да се подсигури анонимно), но не знае дали и за кой си гласувал. Само 3 може да знае (това е опционално, 3 може да не разполага със собственият си публичен ключ и да не може да знае), електронната бюлетина с кой вот е асоциирана, но не знае кой е гласувал. Само 4 може да преброи и да валидира бюлетините, пак без да знае кой е гласувал.
За да компрометираш тайната на вота, трябва да компрометираш всичките едновременно. Това е теоретично възможно за държавата да се организира и да го направи, но това е малко вероятно, защото първо може лесно да се установи (много по лесно от при физическото гласуване, понеже тук всички записи се пазят на всякъде), и второ това не е проблем да се прави и сега, така че за него няма технологичен проблем при присъственото гласуване, има принципен държавен и морален проблем, и не можем да кажем, че е нещо, което ще го докара електронното гласуване. Проблемът ако съществува, ще е проблем е на организацията, държавата и културата.


Тъй като подписите стават локално там където ги извършва гласуващият, то хакер хакнал по отделно 2 или 3 или 4 не може да генерира фалшиви подписи. Нито може да подпише (няма частните ключове или сертификатите при клиента от предната организация), нито да създаде валиден сертификат (защото той изисква участие от край до край). Теоретично е възможно да създаде масови фалшиви подписи ако хакне 1, но пък красотата на всичко тук, е че това може лесно да се установи (от ГРАО, в реално време или постфактум при проверката при 4) и всички гласове генерирани по този начин да се извадят от вота (да се инвалидизират хешовете от 2 или сертификатите от 1 и ще се получи инвалидизация при преброяването при 4), включително пост фактум, отново при запазване на пълна анонимност за гласуващият.


Дублирането е премахнато заради валидацията по активен хеш в организация 4. Но за дублирането ще кажа още нещо по-късно. Всеки електронно гласувал ще има само един единствен валиден вот.


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


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


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


Звучи сложно? На пръв поглед технологията изглежда сложна и многостъпкова. Сигурно ще е трудно за потребителите да я следват? Всъщност не. Идеята с разделението и многото подписвания не е нова и не е случайна. Всъщност тя се изпълнява от ИК и сега, в присъственото гласуване (личната ти карта е сертификат/електронен подпис издаден от МВР, бюлетина с воден знак е сертификат от издателя на бюлетините, проверката по ИК и лична карта и подписа в избирателният списък е еквивалента на получаването на право за гласуване е моята стъпка 2, гласуването в стаичаката и последващият печат върху бюлетината е еквивалента на стъпка 3, валидацията на печатите, и водният знак бюлетините и съдържанието от ЦИК и ИО е еквивалента на стъпка 4). Тази технология с 3-ен подпис е класическата технология използвана от технологията за оторизация KERBEROS на MIT, която до сега не е разбивана, а всъщност е изключително масово употребявана (Active Directory оторизацията в Windows е базирана на нея). Използва се и от свръх популярната OAUTH2 система за оторизация. За потребителят изглежда че попълва данните си само на едно място, но отзад има двойна (или дори тройна) оторизация, и нито една организация не разполага с цялата и пълната информация за личните данни на участника. По важното е, че потребителите дори не разбират как става, и не се налага да се логват на 3 сайта едновременно. Но това не премахва гаранциите за сигурността.


Компрометирани броусъри, операционни системи, троянски коне не компрометират автоматично например електронният подпис (всъщност всички хакове, за които знаем не компрометират системата по същество, а само дебнат ситуация в която потребителят подписва в реално време и се опитват да изземат сесията. Дори да заподозрем 1-2 такива случая, това е невъзможно да се изпълни масово в изборният ден по начин по който да се повлияе на изборният резултат).


За дублиранията – тъй като имаме вторична анонимна проверка (при 4), потребителят може да гласува безброй пъти анонимно (издавайки си безброй бюлетини), и да му се брои само последният вот. Това не само не е недостатък, но може да е и предимство. Дори да бъде принуден от някой “да се гласува правилно” пред него, по късно потребителят може да гласува пак, и да инвалидизира предното си гласуване. Така насилственият вот може да стане много по труден (но не и продаденият, но той не може да бъде преборен с технология – това е лично решение), тъй като хората ще имат алтернатива. Особено в малките населени места локалното влияние (в изборната секция със заплаха от кмета, както често се случва) може да стане много трудно, тъй като хората могат да отидат и пак да си гласуват валидно – другаде.


Тъй като само потребителят може да е в състояние да прочете информацията от подписите си, то системата може да бъде направена така, че потребителят да може да провери как е гласувал (ако се предостави такава услуга от 4) и да открие фалшификации, хакове, или да инвалидизира гласа си. Нещо повече, никой няма да бъде в състояние да му попречи да го направи, или да разбере, че това се е случило, без да има абсолютно цялата информация от 1,2,3 и 4 (а пък ако дори само един се оплаче, това лесно ще се открива проблема и ще се хваща виновника. При добре работеща полиция, много бързо и точно ще се излавят хората опитващи да правят компрометиране на системата).


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


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


До момента няма нито един случай, на наистина хакната система за електронно гласуване или за електронно банкиране. Нямаме познат случай, при който да е хакнат електронен подпис (но знаем за хиляди подправени паспорти). Нямаме случай, в който да е хакнат алгоритъм за оторизация.
Имаме случаи на откраднати (физически) електронни подписи (но както и при личният паспорт, те могат да се инвалидизират и за разлика от личният паспорт инвалидизацията може да е мигновенна). Имаме случаи на откраднати статични сертификати. Имаме случаи на пробити банкови системи по друг начин (достъп до софтуера управляващ трансферите на парите). Имаме класически Denial of Service атаки, които блокират или забавят скороста на работа на системите. Но те не нарушават анонимноста или оторизационната система на потребителите, а са плод на грешен дизайн в други части от софтуера. Така че не могат да се ползват като доказателство за несигурност. Сигурността за личноста и решенията накрайните потребители си се запазва. Но некадърността на системите си е друг проблем.


В предложената от мен схема, нито една организация и дори нито една произволна комбинация от две организации, не може да генерира фалшива система за оторизация, фалшива бюлетина, фалшива асоциация с вот, които да минат на проверка при номер 4. Всички те само ги записват, подписванията прави само потребителят локално.
Можем да имаме (умишлено) фалшиво преброяване при 4, но пък всички сертификати/бюлетини си стоят и подлежат на вторична проверка, така че при всяко подозрение, могат да се проверят и изловят. Доста по добре, отколкото при сегашният модел на присъствено гласуване.


Отделно, една от красотите на цялата работа е, че 1,2,3 и частично дори 4, могат да бъдат реализирани частно, и повече от веднъж едновременно. Можете да имате много издатели на оторизационни системи (електронен подпис), много издатели на електронни бюлетини, много сайтове за асоцииране на вот, много преброители. Това не само че не нарушава сигурността, но дори я увеличава. Потребител, който има подозрения, или ако направи проверка за собственият си вот, какво е гласувал и види несъвпадение, може да смени в рамките на изборният период (ден) и да гласува пак на друго място, и така да инвалидизира грешката, както и да заобиколи проблема. Обратно, полицията пък може да сваля фалшиви сайтове.


Фишинг атаки (сайтове за фалшиво гласувне) няма да сработят, тъй като не разполагат със сертификатите от публичните ключове, както за да вземат гласа на потребителя, така за да го пратят валидно към 3 или 4.


Единствената атака, която остава е DoS атака, към електронните места за гласуване, така че да бъдат блокирани и потребителите да не могат да гласуват и да се нервят. Но DoS атаките се решават лесно, с добре дистрибутирани и скалирани системи. Дори и без атака, системата може да бъде крайно бавна, защото е проектирана лошо (и тук мога да дам пример с Търговският Регистър или сайта за електронно преброяване на предните избори). Но това не е причина да няма електронно гласуване, това може да е причина да притиснем държавните организации да бъдат много по сериозни в разработката на софтуера си.


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


Challenge алгоритъм – Представете си че имате две страни които си комуникират през несигурна среда. Страна А иска да валидира, че страна Б е тази, за която се представя. Страна А знае, че страна Б ще се валидира с информация, която страна А знае (да кажем парола).
Когато Б иска да се представи, той моли А да му даде едно случайно число. А му изпраща случайно число. Б използва случайното число, за да криптира (или hash-не) информацията си, и я подава на А. А знае числото, знае алгоритъма за криптация (hash), и извършва действието на Б локално, след което сравнява резултата с това, което е получил от Б. Ако има съвпадение, значи Б е този, за когото се представя.
Ако някой подслушва мрежата, той знае че Б се опитва да се оторизира пред А. Но не знае паролата на Б, тя никога не минава некриптирана. Отделно не може да използва информацията, получена от Б за да се представи за Б някъде другаде, понеже друго случайно число ще бъде използвано в онази оторизация.
В резултат – имаме активна оторизация, която не може да се декриптира, и не може да се използва другаде или тук по друго време.


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


Електронен Сертификат – Двоен (или повече) подпис с публични и частни ключове. Пример – представете си, че вие си създадете своя двойка публичен и частен ключ. Частният си е винаги у вас. Но искате публичният да е достъпен за група хора или всички. Отивате в полицията (или Certificate Authority) и те проверяват, че вие сте вие. След което криптират с техният си частен ключ информация-текст, която казва – да, това е лицето Пешо Пешев, и неговият публичен ключ е този и този (записан вътре). Полученото нещо се нарича сертификат, и можете да го публикувате публично (или да го изпращате, с криптираната от вашият частен ключ поща).
Всеки, който получи вашият сертификат, ако има публичният ключ на полицията (CA) ще може да го прочете. И ще знае, че полицията (гарантирано от нейният частен ключ) твърди, че вие сте този, за когото се представяте, и вашият публичен ключ кой е. С него пък получателят ще декриптира вашата поща, и ще знае че тя е написана от вас, защото само вие имате вашият частен ключ.


Дифъл-Хелман алгоритъм – друга форма на асиметрично криптиране, при което участниците дори си разменят публично индикатори за ключовете, от които може да се регенерира публичният (или друг) ключ, но подслушващият не може да го направи.


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


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

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

ППС:
Може по детайлно да го разпиша, но основната идея е в разделението. Ако си представим, че асоциацията на бюлетина с вот, е всъщност като действието по създаване на сертификат, само че имаме частен ключ генериран локално, и публичен ключ асоцииран с анонимен хеш, който половината да речем отива при асоциятора на вота и половината при преброителя директно, то асоциатора (3) може само да валидира информацията, но не и да знае кой е гласувал и какво. Преброителя може да валидира, но не и да знае кой е гласувал. Само потребителят, ще има възможност да провери, да чете и да (пре)гласува, локално при него.
Математиката допуска това. Така работят вече и много електронни системи за оторизации. Така че може да стане сигурно. Въпросът в действителност обаче никога не е бил технологичен, нали?