Um, CFC? how are chlorofluorocarbons utilised as an authentication mechanism? A QR code isn't a form of validation or authentication. It's a machine readable code, like a bar code. It's suitable to identify individual hardware assets but due to it's ease of adjustment can't be considered physically assured authentication(anyone can add a sticker) and due to it's ease of replication, cannot sensibly used as any type of security mechanism. Biometrics isn't the most sensible either. To take the example of fingerprints, It's possible to 2D print or 3D fingerprints using commonly obtained equipments and materials and even if it wasn't, it's just encouragement to start cutting bits of you off. Truely secure authentication is something unique, not easily transfered(cutting people's fingers off, removing their eyes, sampling their blood, hair etc is trivial) and preferably would contain a duress feature where in a state of duress you can release information that when attempted to use as aditional auth to unlock will nullify and lock the account.

I would highly encourage asking questions, Sultanovich - the more awkward, the better. It might give me something interesting to think about. Why should you(or indeed anyone) take what I(or anyone else) say(s), on face value alone, to be true? I certainly wouldn't expect it, instead expecting you to simply use anything I say as points of research in order to draw your own conclusions.

To use the online voting model as example, If we was to open source all our "backend" software, and to further run this on open source hardware(to avoid various cryptographic backdoors implimented in "modern" CPU, and worse things like on-chip 3G, remote access to the core that controls all the other cores with higher privilige than the physical user etc and other deficits of SoC like hardware added to reduce security) then all facets of the systems are observable, without actually impinging upon used hardware. Then the only question of trustability would be the prospect of adding either additional code or hardware to the system to provide behaviour not sanctioned in the "intended" design. The sum hardware ID's of a machine can be hashed, and common technologies utilised in things like ATM can prevent booting once the system itself detects unautherised hardware(monitoring it's own power draw can additionally provide indication of extra things) as can each individual software, or software collections, and then these hashes further hased to provide a single checkable authenticator. To use a sensible hashing algorithym would result in a unique, repeatable hash that will result in confirmation that the hardware and software is as expected matching published hashes, which would be possible to independantly reproduce for confirmation.

Then the measurement of trust is thus to the extent of can you trust the admin team can accurately relay the reported hash. To that extent, to assume a paper ballot system, how can you be sure they actually counted it and didn't just make it up as they go. On that subject, if you can't be trusting them to be able to accurately relay information, then you really don't want these people in any way involved with anything where it can impact operations of "sensitive" infrastructure. You certainly don't want these people involved with defining or upholding security procedures.

Cfc is an authentication card that means functional layer card, this is in Portuguese, unfortunately the translator did not do a good job. The qr code sim is a bar code, but the authentication information that comes to be filled after it is scanned and what differs. All that was once known as a secure method of authentication today is not so secure. I saw your proposal and I know it's possible.

So you'd be talking about something along the lines of PKCS 11? X.509?

I've never occured QR used for anything other than inventory tracking and asset management. I can envision no way this could be used as a "security feature". As an authentication source, it's a rediculous concept for the ease of which an existing can be simply photocopied, snapped with a phone and printed etc.

Is layered authentication. 1. The cell phone or computer must be registered in asgardia through a plug or plug. 2. scan the qr code or put the token on the pc 3. will open a form. 4. Choose your candidate and confirm.

Even so it can be rigged. That is, we need something that is practical for everyone and at the same time safe.

In my governmental project we used card and card reader, with SSL certificate X509. The card had a PIN with 3 tries so we can acess to the key. We payed for a central authority to assure the validity of our keys.

Nos system is secure, but I think it was quite safe :)

Second verification stage using cell phone with a one time password in two stages

US Govt Security Engineer here. PIV login and authentication is one of the most secure methods we can implement today that wouldn't be incredibly expensive given their mainstream use today. We should be considering factoring in PIV chips into all Asgaridain ID's from the very beginning and shipping card readers or selling them at a discount to our citizens.

Somewhere else(dealing with passports) I had suggested implimenting X.509/PCKS 11 in passports, on additional data "pages" in order for use as "ID verification", locked by passphrase this should be easier for long term recall for citizens. Armed with additional duress password, it can be rendered useless in a state of duress. In the current ecosystem of, it's going to almost assuredly be a requirement of acceptence as a valid travel document(pending ofc, recognition as nation) and is certainly featured in the list of best practices regarding creation of.

The readers are a cost factor, but especially buying them in bulk it should only raise overall individual passport costs by an infinimetessimal amount. Somewhere else adressing the funds required to start producing passports, I pulled a random number of $10,000,000 USD (and we can do it for a lot less, I'm sure) out of nowhere, and it's not particularly disabling as a per-citizen fee, and rivals even beats many countries per-passport fee. Even with buying/building the facilities to my standards (exceeding IACO standards), plus 50% for keeping the facility running in terms of materials, facility operators, making available CRL etc and including a reader with the passport we're looking at less than $40USD/head.

I think we could posibly look into producing these readers ourselves.. people with pick n place machines, reflow ovens, 3D printers... Network up and distribute the load. Could pull off the entire operation for pretty much materials cost. To assume a common connection standard of USB, we can pick packages that will commonly deploy to operational requirements under the most generic of drivers on all popular operating systems, and include any additional hardware we would like - Say a few GB of flash presented to the user read-only containing our software/drivers - or possibly even an entire OS to boot from USB. Supplied with these, it should be possible to then augment Asgardian services to use the physical presence of the passport, made accessible by the correct passphrase to X.509/PCKS 11. IF the reader/passport involves NFC or similar, shielding must be provided to the user(possibly in the passport cover) in order to prevent this from being read at distances of about thirty feet with cheap OTS hardware.

To assume the cellphone/QR model, by providing the "Vote" details from the server, you can totally do away with the QR code. Being publically readable with conventional hardware and requireing no particualr authentication method to do so, it's unsuitable to put anything more than a link in there. Unless we use a different DNS for each election, the same one can be recycled over and over.. You also don't seem to of identified of a secure method to get the QR to the phone, it strikes me as it's likely this method could use the token directly without the user's interaction. Further the second you introduce a phone into the mix, you've instantly removed all security, there's a reason no secure area anywhere accepts even their presence, let alone use. It's the same reason none of these commonly available devices get DoD clearance. To address "Second verification stage using cell phone with a one time password in two stages" - how do you plan on getting that to the phone? Through the public network that collects and processes every text/email/call? Either by your nation of residence, one of their peers who will share this information, or by a foreign nation. Registering a phone with Asgardia is of no consequence. What factor are you planning to consider unique for auth? The IMSI? That's easily spoofed, or with access, cloned. The ICCID? Again, easily spoofed, or with access, cloned. The IMEI? Guess what? That's easily adjusted too. The certificate the SIM uses for auth on the network? Well that would assume the generation algorithm hasn't been doctored(and within certain build dates, is assuredly doctored, after those build dates almost assuredly generated on hardware that will take shortcuts that lead to statistical, predicatable, weakness and further assumes service providers will not make them available for the "right" people, and be able to stop them just taking it). Consider also hardware based backdoors to the device. Interesting the specific requirement for the CPU to cache any encryption key it processes - With the magic of SoC there's a lot you'll never find without an electron microscope, and being tightly integrated inside components attempting to remove it will render the device inoperable... Also doesn't matter what you do with software, hardware wins. Then additionally consider the user. The average user isn't likely to understand what secure actually is - and to pretend the hardware was secure when they started, then the common user's digital habits are likely to rapidly render insecure even the most hardened device. Most don't question what else the software does. That last PEBCAK argument stands equally well for computers, but I feel commonly simple measures can be taken to lend the greater number of devices at least the perception of secure, to anything but a few nation state actors - and once we get people more suitable than me designing hardware for us it might actually be possible to build a secure (set of)system(s), that is ofc, open source.

@EyeR, my English is really bad. Could you clarify what this means?: I would highly encourage asking questions, Sultanovich - the more awkward, the better. I do not understand if it's a compliment, a joke or it's just an expression.

What I wanted to explain is that before the technical problem we have a problem of concept. I mean: suppose I don´t know anything about informatics, but I want to be a citizen of asgardia. How can you be sure that my intention to vote is what is actually recorded? With a paper vote most people can verify this, because there is no third party between their intention to vote and the registration of the same (and even there we have the problem of the part of the population that is illiterate).

I am not saying that it isn´t possible to vote online, what I say is that from the beginning we have to choose whether the vote is secret (and have some doubts about the final result) or that the vote is accurate and secure (but we would have That know who to vote each one).

In addition to this initial problem, the next problem (and not that it is smaller or simpler) is how we can provide the highest security for the voting process itself.

One time password using a program? I know that there is not a bulletproof system but what will cost to make our own system (hardware & software) to be secure (ps dont forget the humman factor), and even if we succefully create them how safe is to deliver them to citizens without been affraid of the chance of someone to put a software into the machine for creating a backdoor

As to "compliment, a joke, or expression" - all of the above in lesser or greater extents. Ofc it was also meant in seriousness, and exactly as it says. Asking questions is a good thing, and the more awkward they are the better.

There's really no difference, in conceptual form, between the paper vote and digital. In both cases options are presented, and in both cases you assume behind the scenes the count is noticed. How can you ensure your paper ballot box wasn't simply incinerated and replaced with a box of pre-filled paper forms? There is a third party in the parper system, the person(s) counting the votes. Or feeding the votes into counting machines. A purely digitised system removes humans from almost all stages, bar the voting. The capability of verification exists for both formats, but is easier and more assured (implimented correctly) with digital.

The highest possibly levels of security for the voting itself has already been highlighted. PCKS11 and or X.509 can assure validity of citizen, a VPN can provide access to a voting system only citizens can access(not exposed to interwebs) and a single-use token can be passed between the user and the voting system to protect the users' physical identity.

One-time pads are not a poor feature, and what makes OTR so secure, it's possible to layer this additionally into the transport model. If we make something ourselves there's very little chance of inserting a backdoor. Any attempt at such would adjust it from the open sourced data for the hardware and or the software and available payload would hash differently, indicating change from published.

@EyeR, what you indicate about the problems of voting systems in paper and electronic format are correct. But it is also true that if someone burns (or replaces) an urn will not influence the final result as it will cause me to change a line of code that applies to the entire voting system. With a paper voting system someone's ability to commit fraud is partial (in the worst case it will affect the total result).

And this is maintaining the problem that I choose my candidate (on the voting web for example) and I can not be sure what the system is recording (unless I have a secondary system totally isolated from the first to verify my vote ). And here, without wanting to be recurrent, how can I be sure that the second system is totally isolated from the first? (If I do not have any knowledge of computer science).

In Argentina in 2015 a project was started to modify the vote in paper to electronic vote. To give an idea, an official at a time of debate ensured that the electronic equipment that would be used for voting had a "farahay cage". A FARADAY CAGE !!!, something derisory for those who understand something electronic or infirmatica, but that people without technical skills are unable to verify.

A faraday cage only prevents extranal waves. Physical access mitigates this, easily.

By publishing the code used in the voting system, those concerned about are able to view, by publishing hashes it's possible to verify the code used is as advertised with no modificaitons. It's possible to do the same for hardware.

This would still leave the question of being able to trust the system itself is actually used in the vote count - but this raises no additional concerns as to a paper-based physical system. If you have no trust in this, or those operating, why even bother entertaining the voting system? Paper or digital, that still applies.

I don´t know how voting is carried out on other continents nowadays, but generally in America it is voted in schools. Do you think it might be feasible to build a faraday cage in each of the schools in the country? I think it's impossible.

Returning to Asgardia, the problem we continue to have although the code and specifications are open source is that not everyone has the ability to analyze it. I mean, if I don´t know the specific language in which it is done and I am not a programmer, even if I have the source code, I can t assure you to do what it says it does. But if I could do it with a paper, because just seeing a tilde or the name of a candidate can suffice.

I repeat, it is not a question of believing or not believing. I can believe today or not in the current voting system of my country (which is on paper), but if I wanted, I could verify it manually without needing any specific knowledge.

For this reason it is that I say that if the vote we want it to be secret all the citizens of asgardia could not be sure that what they voted is what really was counted.

It does not occur to me yet how we could offer the Asgardians voting information without violating the secret of the vote.

Many places recycle other civic facilities, not just America. Faraday cage is a bit useless in as much as it only shields from transmission - simply don't include any wifi/bluetooth/zigbee etc hardware and have the input TEMPEST shielded(restricted tech, but meh) and you can save the cost of needlessly enclosing an entire building in a faraday cage. It's also useless because it won't shield from anyone inside the cage. If it's the machine itself you'd be more thinking of enclosing, then physical access to the machine mitigates. Sensibly there wouldn't be anything like wifi, and if it's unavoidable any link would be protected to a far greater standard offered by the common connection types you'd be used to as a home user. Even wrapping the connection "home" through a VPN should suffice to keep external observers shoeless. If it's interference with the running software that causes concern, then quite simply don't have any listening services. With nothing accepting input, it's pretty difficult to give it some.

True, you may not speak the language used to create the service - but someone somewhere will. If you can't understand it, then maybe they can explain it - or you can just trust that anyone that does speak it poking through will be vocal about anything found. Anything of a "security" nature tends to feature a fair amount of attention anyway, but I suspect this particular system would be put under particular scrutiny by Asgardians. Anything questionable will be met with much contraversy. If following good coding practices, the code should be littered with comments that would enable someone who can't code to follow along. Should you distrust that the comments actually marry what is happening in the code, you can start to look up what those sections do. Should that still not provide enough information to grok with confidence then you can take advantage of the greatest facet the interwebs allows for you - to connect to other minds and utilise the information within. Places like stackoverflow will happily accept either extracts of code, or links to code, and if you ask the right questions you generally get the right answers. For a case in point, examine: http://dpaste.com/0R96CYM. To claim I'd written that would be a little strong being mostly copied n pasted open source. But it should be commented clear enough so should you not speak C then you've a chance of understanding which part of the code is responsible for what. But how can you know those comments accurately portray the code's actions? look it up. To take the line(s):

   //black out the screen so nothing from previous run shows.
  tft.fillScreen(ST7735_BLACK);

To assume the function name isn't revealing enough, throwing "tft.fillScreen();" into your fave search engine would be a good start, looking for where it came from - links to the adafruit library it came from should be prominent - but to assume reading the library itself won't be of much "help" then look for other people's use of, sometimes the context in which it's used can be revealing. Else paste it stack overflow - or somewhere that contains a pretty heavy ration of people likely to know of such - and ask 'em to kindly reveal what the code is actually doing. Once several independant sources come up with the same story, you've a reasonably confident chance of defining what's happening with never having a requirement to understand code..

To compare to the paper ballot system... You could verify that manually, in theory. If you could get near it - but how could you verify that was actually the slip you filled out? or the same for any other given. You've no measure of assurance these were not filled months previously to replace the original one you filled out once it's been destroyed. You've no assurance that these votes are even counted, and the total tally just made up as they go along. Once that's taken out of your sight you're back to the trust model. You have no way to independantly verify either an individual vote, or the entire count.

I don't understand how offering voting information violates the secrecy involved in that actual vote selected - with either model .