Come viene garantita la sicurezza del calcolo distribuito?

Ottenere risultati falsi o distorti dalla potenza della CPU fornita dagli utenti è un vero problema che non ha una soluzione pratica nota, ma esistono diverse strategie di mitigazione:

• Duplicazione . Per ogni dato blocco di lavoro, assegnalo a due contributori distinti e confronta i risultati. Questo intrappolerà la maggior parte dei frodatori e anche gli errori di calcolo dovuti a una cattiva RAM; sfortunatamente, questo dimezza anche la potenza di calcolo disponibile. Questa strategia è stata utilizzata da alcuni miei amici che (in breve) hanno ottenuto il record mondiale per il problema N queens (cioè conteggio di tutte le soluzioni: lo hanno calcolato per N = 23 nel secolo precedente).

• Campionamento . Questa è una variante della soluzione precedente, in cui si duplicano solo blocchi alcuni , ad es. uno su dieci (scelto a caso). Questo intrappolerà i frodatori che ottengono risultati di gioco almeno occasionalmente, mentre incorrono in costi minori. Devi tenere traccia di chi ha fatto quale pezzo, in modo che i valori sospetti possano essere rimossi in massa .

• Incentivi . Se il lavoro è di persuasione del ritrovamento-ago-in-pagliaio (come uno sforzo di cracking di chiave distribuita), allora puoi annunciare un premio importante per chi lo trova. Ciò indurrà molti potenziali cheater a fare effettivamente i calcoli, dal momento che non farli significa che non otterranno il premio.

• Codifica completamente omomorfica . Quella è una soluzione generica, ma l'algoritmo più noto per FHE ha l'inconveniente scomodo di incorrere in un sovraccarico che è contato in miliardi - cioè anche se l'intera Internet ha contribuito al calcolo con FHE, non corrisponde a quello che potresti ottenere senza FHE su un singolo PC.

• oscurità . Il preferito di tutti i tempi delle strategie anti-cheating: semplicemente non mostrare la fonte, mantenere segreti i protocolli e sperare che nessuno si preoccupi di eseguire un debugger e fare un po 'di reverse engineering. In uno scenario simile di calcolo distribuito, ovvero i giochi online, non funziona bene .

• Fortuna e fiducia . Prega semplicemente che non ci saranno troppi truffatori e che i frammenti più saranno elaborati come dovrebbero. A seconda del tipo di calcolo, questa potrebbe essere una strategia valida. Ad esempio, potrebbe funzionare per uno sforzo di cracking chiave, dal momento che alcuni pezzi saltati non contano (a meno che la chiave non sia in uno di essi, che sarebbe sfortuna ma improbabile se la maggior parte dei contributori è onesta). Non funzionerebbe per un conteggio completo in cui si aggiungono tutti i risultati (ogni valore errato modificherà il totale).

Storicamente, distributed.net ha riscontrato tali problemi nei loro sforzi di cracking DES / RC5. Alcune persone potrebbero falsificare i risultati, cioè alterare i loro clienti in modo che rispondessero "lavoro fatto, nessuna chiave trovata" senza eseguire i calcoli ; i clienti gamed risponderebbero più velocemente dei clienti che realmente fanno il lavoro. Lo stavano facendo solo per essere in una posizione migliore nella lista dei contributori, ordinati dal potere della CPU (retrospettivamente, era abbastanza ovvio che il proprietario del computer avrebbe agito proprio come fanno i proprietari di auto). La loro risposta era un cliente oscuro senza fonte, che era sufficiente in quel caso (troppe poche persone hanno fatto il reverse engineering per imbrogliare di nuovo).

Esiste anche il duplice problema , cioè: come ci si assicura, come contributore , che il codice client che ti mandano è davvero benigno? Questa non è una domanda facile, ed è resa più difficile dal codice client closed-source ...

Linux include una chiamata di sistema elegante chiamata seccomp () che potrebbe essere utile per questo. E, almeno teoricamente, questo potrebbe non essere sufficiente per un isolamento completo di un processo potenzialmente fuorviante, perché quel processo condividerà le cache (cache L1, previsione di salto ...) con altri processi, ed è stato dimostrato che è utilizzabile ( in condizioni di laboratorio ) per recuperare una crittografia chiave.

Lo spyware è semplice, garantisce che i dati che tornano seguono un determinato formato e non ne eseguono alcuna parte. Non è diverso caricare file JPG su GMail o Tumblr: qualsiasi cosa tu carichi non verrà eseguita in alcun modo, quindi è OK.

Riguardo a "falsificare i dati":

Per uno, generalmente inviano gli stessi dati a più di un utente. In secondo luogo, i suggerimenti di un "evento interessante" saranno ovviamente controllati da un essere umano. Naturalmente, se "nascondi" le tue scoperte, non c'è molto che possa essere fatto se non verificando la tua sottomissione con qualcun altro.

Il loro sito web è attualmente inattivo, ma ho trovato questo in una copia delle FAQ di SETI @ HOME :

What if someone fakes a result to make it seem like they found a signal?

The SETI@home staff will be reviewing the actual data that produced the result, and if they don't find the same results, they will discard the fake. Besides, while it's not impossible, it might be harder than you think to fake a result file.

Since some workunits are sent out more than once, SETI@home can detect errors by comparing the results. During the time of the project, the sky will be scanned several times. It's very unlikely that a cheater would get a workunit from the same location in the sky more than once.

Una buona lettura su questo sarebbe questo pdf ^{( doi )} , che spiega un modo piacevole in cui i sistemi possono proteggersi dagli spoofing degli utenti.

In this paper, we first propose a scheme called Quiz to combat collusion. The basic idea of Quiz is to insert indistinguishable quiz tasks with verifiable results known to the client within a package containing several normal tasks. The client can then accept or reject the normal task results based on the correctness of quiz results.