Jan 2, 17 / Aqu 02, 01 18:23 UTC
Re: How to secure on-line voting? ¶
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.