Discussioni sulla computer security
 

Gare, buste sigillate, microcamere, PEC e allegati...

Renaissance 29 Giu 2016 12:06
Salve a tutti,

Premessa:
"Una microtelecamera nelle buste, così gli amici
vincevano gli appalti". http://goo.gl/ZaBQ4g

http://www.bosettiegatti.eu/info/norme/statali/2016_0050.htm#052

Cit.: <<5. In tutte le comunicazioni, gli scambi e l'archiviazione di
informazioni, le stazioni appaltanti garantiscono che l'integrità dei
dati e la riservatezza delle offerte e delle domande di partecipazione
siano mantenute. Essi esaminano il contenuto delle offerte e delle
domande di partecipazione soltanto dopo la scadenza del termine
stabilito per la loro presentazione.>>

Molte offerte vengono fatte oggi via PEC, e ovviamente e' assai meno
sicuro della busta sigillata con ceralacca, visto che in ogni momento,
alla faccia della scadenza, si possono visionare le offerte. Cosi'
e' ancor piu' facile dire all'amico, che e' quello che invia l'offerta
per ultimo, "ehi, applica questo ribasso, se vuoi vincere".

Mi chiedo: quale altro metodo tecnologico ci sarebbe per impedire cio',
a parte quello di crittare i ******* in modo forte (RSA a 2048 bit), e
poi la ditta spedisce, sempre via PEC, la chiave di decrittazione dal
momento in cui l'ente puo' aprire le buste?

bye G.L.

ps.: Ho visto che esiste anche un programmillo che permette di settare
un expiry date, ma quello e' per impedire la decrittazione anche
conoscendo la password corretta...
--
Da i.d.c.tutela:
P.S. Quando ci sarà lo switch-off, avrò problemi anche col
monitor del PC? Ho visto che è collegato in modalità *****ogica.
Paolo C. 29 Giu 2016 20:00
Il 29/06/16 12.06, Renaissance ha scritto:

>
> Mi chiedo: quale altro metodo tecnologico ci sarebbe per impedire cio',
> a parte quello di crittare i ******* in modo forte (RSA a 2048 bit), e
> poi la ditta spedisce, sempre via PEC, la chiave di decrittazione dal
> momento in cui l'ente puo' aprire le buste?

Inviare la pec 10 secondi prima della scadenza?
(il concorrente non avrebbe tempo per correggere la sua e inviarla)


>
> ps.: Ho visto che esiste anche un programmillo che permette di settare
> un expiry date, ma quello e' per impedire la decrittazione anche
> conoscendo la password corretta...

mi chiedo come possa funzionare visto che sapendo l'algoritmo e la
chiave un ******* è sempre decrittabile; anche se il programmino di
decrittazione fosse programmato per non funzionare dopo una certa data,
sarebbe facilmente *****abile o ingannabile facendolo girare in una
virtual machine, ecc
Andrea D'Amore 30 Giu 2016 07:57
On 2016-06-29 10:06:50 +0000, Renaissance said:

> Mi chiedo: quale altro metodo tecnologico ci sarebbe per impedire cio',
> a parte quello di crittare i ******* in modo forte (RSA a 2048 bit), e
> poi la ditta spedisce, sempre via PEC, la chiave di decrittazione dal
> momento in cui l'ente puo' aprire le buste?

Mandare le offerte criptate senza chiave entro una data, le offerte
vengono inserite in un registro pubblico tanto non sono consultabili,
rilasciare le chiavi la mattina dell'apertura delle "buste
elettroniche".
In questo modo ognuno è sicuro che la propria offerta non sia già stata
aperta prima e chiunque può verificare che il ******* che viene aperto è
quello che era presente prima del termine della gara.

--
Andrea
Pistore Sebastiano 30 Giu 2016 09:40
Il 30/06/2016 07:57, Andrea D'Amore ha scritto:
> Mandare le offerte criptate senza chiave entro una data, le offerte
> vengono inserite in un registro pubblico tanto non sono consultabili,
> rilasciare le chiavi la mattina dell'apertura delle "buste elettroniche".
> In questo modo ognuno è sicuro che la propria offerta non sia già stata
> aperta prima e chiunque può verificare che il ******* che viene aperto è
> quello che era presente prima del termine della gara.
>
Parrebbe perfetto dal lato della sicurezza.
Però non mi sembra facilmente applicabile: dovresti avere un certificato
X.509 per ogni gara e chiedere alla CA di non metterlo sui server prima
di una certa data (e neppure *DOPO* :)

Usando invece pgp non potresti farlo (anche se la pubblica
amministrazione sapesse cos'è): dovresti rilasciare la chiave pubblica
in anticipo per farla firmare.
Leonardo Serni 30 Giu 2016 14:39
On Thu, 30 Jun 2016 09:40:35 +0200, Pistore Sebastiano
<NomeVeloce@MaestroDiDante.it> wrote:

>Però non mi sembra facilmente applicabile: dovresti avere un certificato
>X.509 per ogni gara e chiedere alla CA di non metterlo sui server prima
>di una certa data (e neppure *DOPO* :)

>Usando invece pgp non potresti farlo (anche se la pubblica
>amministrazione sapesse cos'è): dovresti rilasciare la chiave pubblica
>in anticipo per farla firmare.

Ti limiti a non includere l'ammontare dell'offerta, ma solo la sua versione
crittografata con AES ed una chiave di tua scelta ("battery horse staple"),
via PEC.

Il giorno dell'offerta comunichi la chiave, via PEC pure quella.

Se la decodifica non avviene correttamente, l'offerta è cassata: altrimenti
l'offerta è verificabile senza problemi, e senza chiave non c'è versi.

Leonardo
--

A terrible beauty is born.
- W. B. Yeats, Easter 1916
Paolo C. 30 Giu 2016 15:40
Il 30/06/16 14.39, Leonardo Serni ha scritto:

>
> Ti limiti a non includere l'ammontare dell'offerta, ma solo la sua versione
> crittografata con AES ed una chiave di tua scelta ("battery horse staple"),
> via PEC.
>
> Il giorno dell'offerta comunichi la chiave, via PEC pure quella.
>
> Se la decodifica non avviene correttamente, l'offerta è cassata: altrimenti
> l'offerta è verificabile senza problemi, e senza chiave non c'è versi.

Perché non crittografare *tutto*, allora?
Andrea D'Amore 1 Lug 2016 07:43
On 2016-06-30 07:40:35 +0000, Pistore Sebastiano said:

> Usando invece pgp non potresti farlo (anche se la pubblica
> amministrazione sapesse cos'è): dovresti rilasciare la chiave pubblica
> in anticipo per farla firmare.

Pensavo proprio a GPG o comunque ad un approccio a chiave asimmetrica,
ma perché dici che si dovrebbe far firmare la chiave pubblica del
concorrente?

Ad ogni modo non ci vedrei problemi nel rilasciare le chiavi pubbliche,
il punto è che rilasci un pubblicamente un documento per stare nei
limiti temporali della gara, alla lettura produci la chiave privata e
la tua proposta viene letta.


--
Andrea
ArchiPit 1 Lug 2016 08:41
Rispondo quì sotto a Andrea D'Amore


> Ad ogni modo non ci vedrei problemi nel rilasciare le chiavi pubbliche, il
> punto è che rilasci un pubblicamente un documento per stare nei limiti
> temporali della gara, alla lettura produci la chiave privata e la tua
> proposta viene letta.

Mi domandavo.....

Uno potrebbe inserire nel ******* criptato dell'offerta due o più
"offerte" commerciali: all'apertura delle buste l'offerente sceglie
quale offrire dando la chiave di decriptazione corrispondente.

In pratica, con la prima chiave potrei rendere disponibile il mio
prezzo base; se invece subodoro (a posteriori rispetto all'offerta, ma
prima di qualunque apertura delle buste) prezzi più competitivi da
parte di altri comunico la chiave bis che offre un prezzo minore, e se
non basta la chiave tris....

Insomma, fatta la legge, trovato l'inganno.

Ah, quanto erano belle le offerte ai tempi della cera lacca e dei
timbri a secco, dei sigilli apposti alle 4 di mattina sulle valigione
da emigrante inizio '900, di cartone usa e getta, in albergo, col
rischio di mandarte a fuoco tutto!... :-)
Paolo C. 1 Lug 2016 09:13
Io proverei questo metodo piu' semplice:

i concorrenti realizzano i l'offerta tecnica ed economica, tutto insieme
in un ******* di testo (eventuali allegati grafici verranno inviati dopo,
il testo deve essere comunque esaustivo). Il testo non deve contenere
nessun carattere fuori luogo, stringhe a caso, ecc (*)

Entro il giorno X i concorrenti devono inviare l'MD5 del .txt in
questione, che verrà pubblicato.

Poi, il giorno dopo (**) devono inviare il .txt vero e proprio e si
controlla se l'MD5 torna altrimenti il concorrente è fuori.



(*) in modo da evitare che, magari con una potenza di calcolo
fichissima, il concorrente possa cambiare l'offerta, aggiungendo qualche
byte in fondo al ******* opportunamente confezionato in modo da creare un
hash collision e simulare che sia quello il ******* originale.
Eventualmente se si ha paura dell'hash collision si possono usare piu'
metodi di hash contemporaneamente.

Ho scelto .txt perché appunto deve contenere i bytes del testo e solo
quelli e se uno aggiunge bytes per "farsi tornare" l'hash verrebbe
sgamato. Si tratta comunque di fantascienza, non credo sia così facile
creare un hash collision; pero' nel pdf, teoricamente, un software
apposito potrebbe "s*****are" le parti grafiche un po' a caso, tantissime
volte, e calcolare l'hash finché non torna quello originale, una sorta
di brute force.

(**) un tempo insufficiente perché gli altri concorrenti tramite brute
force riescano a risalire al .txt originale dall'hash
Leonardo Serni 1 Lug 2016 11:00
On Fri, 01 Jul 2016 08:41:33 +0200, ArchiPit
<Bruram48CheOreSono@LeTreDiNotteVirgilio.it> wrote:

>Uno potrebbe inserire nel ******* criptato dell'offerta due o più
>"offerte" commerciali: all'apertura delle buste l'offerente sceglie
>quale offrire dando la chiave di decriptazione corrispondente.

Non funziona in questo modo. Questo tipo di "plausible deniability" deve essere
inserito nel protocollo di crittografia, per esempio ce l'aveva TrueCrypt.

Altrimenti, tu non vedi "un ******* , vedi "un ******* con tre oggetti"... il
che già
lo squalificherebbe. Comunque, se la password di tre oggetti ne apre uno, muore
il gioco.

Leonardo
--

A terrible beauty is born.
- W. B. Yeats, Easter 1916
NomeVeloce 1 Lug 2016 13:04
Il 30/06/2016 14:39, Leonardo Serni ha scritto:
> On Thu, 30 Jun 2016 09:40:35 +0200, Pistore Sebastiano
<NomeVeloce@MaestroDiDante.it> wrote:
>
>> Usando invece pgp non potresti farlo (anche se la pubblica
>> amministrazione sapesse cos'è): dovresti rilasciare la chiave pubblica
>> in anticipo per farla firmare.
>
> Ti limiti a non includere l'ammontare dell'offerta, ma solo la sua versione
> crittografata con AES ed una chiave di tua scelta ("battery horse staple"),
> via PEC.

In che senso non gli includi l'ammontare dell'offerta? Nel senso che la
parte tecnica e quella amministrativa la mandi tramite il MePa mentre
quella economica a parte?

> Il giorno dell'offerta comunichi la chiave, via PEC pure quella.
>
Non so se accettano queste "variazioni": in teoria potrebbe anche andare
perchè l'offerta economica dovrebbe essere l'ultima che aprono.
NomeVeloce 1 Lug 2016 13:06
Il 01/07/2016 11:00, Leonardo Serni ha scritto:
> On Fri, 01 Jul 2016 08:41:33 +0200, ArchiPit
<Bruram48CheOreSono@LeTreDiNotteVirgilio.it> wrote:
>
>> Uno potrebbe inserire nel ******* criptato dell'offerta due o più
>> "offerte" commerciali: all'apertura delle buste l'offerente sceglie
>> quale offrire dando la chiave di decriptazione corrispondente.
>
> Non funziona in questo modo. Questo tipo di "plausible deniability" deve
essere
> inserito nel protocollo di crittografia, per esempio ce l'aveva TrueCrypt.
>
> Altrimenti, tu non vedi "un ******* , vedi "un ******* con tre oggetti"... il
che già
> lo squalificherebbe. Comunque, se la password di tre oggetti ne apre uno,
muore
> il gioco.
>

Infatti: se la commissione non riesce a leggere tutta la documentazione
allegata scarta l'offerta. Già successo (per altri motivi, ovviamente).
Leonardo Serni 1 Lug 2016 13:42
On Fri, 1 Jul 2016 13:04:16 +0200, NomeVeloce <NomeVeloce@MaestroDiDante.it>
wrote:

>>> Usando invece pgp non potresti farlo (anche se la pubblica
>>> amministrazione sapesse cos'è): dovresti rilasciare la chiave pubblica
>>> in anticipo per farla firmare.

>> Ti limiti a non includere l'ammontare dell'offerta, ma solo la sua versione
>> crittografata con AES ed una chiave di tua scelta ("battery horse staple"),
>> via PEC.

>In che senso non gli includi l'ammontare dell'offerta? Nel senso che la
>parte tecnica e quella amministrativa la mandi tramite il MePa mentre
>quella economica a parte?

Intendo che la voce "ammontare" è lasciata in bianco, e nel documento c'è
invece
un pezzo crittografato; l'ammontare è lì, illeggibile fino al giorno X.

Leonardo
--

A terrible beauty is born.
- W. B. Yeats, Easter 1916
ArchiPit 1 Lug 2016 13:54
Rispondo quì sotto a Leonardo Serni

> Non funziona in questo modo. Questo tipo di "plausible deniability" deve
> essere inserito nel protocollo di crittografia, per esempio ce l'aveva
> TrueCrypt.
>
> Altrimenti, tu non vedi "un ******* , vedi "un ******* con tre oggetti"... il
che
> già lo squalificherebbe. Comunque, se la password di tre oggetti ne apre uno,

> muore il gioco.

Cioè, il Cliente giustamente stabilisce il protocollo di crittografia
con la "assoluta" impossibilità di nascondere qualcosa o di switchare
tra una prima e una seconda?

Ho usato tempo addietro la possibilità di TC di nascondere nel *******
container una sezione posticcia e la sezione vera, non ricordo però se
per aprire quella vera occorra dare le due chiavi o una sola.
Mi sembra di ricordare una sola, o la prima o la seconda, con ognuna
che apre la propria sezione del ******* container.

Ma naturalmente nel caso di gare non si usa Truecrypt, peraltro non più
manutenuto...
Paolo C. 1 Lug 2016 15:41
Il 01/07/16 13.54, ArchiPit ha scritto:

> Ho usato tempo addietro la possibilità di TC di nascondere nel ******* >
container una sezione posticcia e la sezione vera, non ricordo però se
> per aprire quella vera occorra dare le due chiavi o una sola.
> Mi sembra di ricordare una sola, o la prima o la seconda, con ognuna che
> apre la propria sezione del ******* container.

Una sola. Però truecrypt gioca sul fatto che in un "container" criptato
è normale che il ******* container sia piu' grande del suo contenuto.
A quel punto siccome lo spazio non allocato viene riempito con dati
"random", truecrypt gioca sul fatto che i dati "random" dello spazio non
allocato non sono veramente random ma sono dati crittografati che
sembrano random.

L'amministrazione potrebbe dire: signori, insieme al ******* criptato
dovete inviarci l'hash del ******* non criptato. A quel punto non c'è
possibilità di estrarre una cosa piuttosto che un'altra.
Renaissance 1 Lug 2016 15:43
Il 30/06/2016 14.39, Leonardo Serni ha scritto:

> Ti limiti a non includere l'ammontare dell'offerta, ma solo la sua versione
> crittografata con AES ed una chiave di tua scelta ("battery horse staple"),
> via PEC.

> Il giorno dell'offerta comunichi la chiave, via PEC pure quella.

> Se la decodifica non avviene correttamente, l'offerta è cassata: altrimenti
> l'offerta è verificabile senza problemi, e senza chiave non c'è versi.

Imho bisogna crittare TUTTO: anche il contenuto dell'offerta, se non
regolare, puo' dare adito a turbativa d'asta... (ok caro amico, sappi
che l'offerta di un tuo concorrente verra' cassata per non conformita')

bye G.L.
--
Da i.d.c.tutela:
P.S. Quando ci sarà lo switch-off, avrò problemi anche col
monitor del PC? Ho visto che è collegato in modalità *****ogica.
ArchiPit 1 Lug 2016 23:40
Rispondo quì sotto a Paolo C.


> Una sola. Però truecrypt gioca sul fatto che in un "container" criptato è
> normale che il ******* container sia piu' grande del suo contenuto.
> A quel punto siccome lo spazio non allocato viene riempito con dati "random",
> truecrypt gioca sul fatto che i dati "random" dello spazio non allocato non
> sono veramente random ma sono dati crittografati che sembrano random.

Ok, allora ricordavo bene...

> L'amministrazione potrebbe dire: signori, insieme al ******* criptato dovete
> inviarci l'hash del ******* non criptato. A quel punto non c'è possibilità
di
> estrarre una cosa piuttosto che un'altra.

Giusto.
Semprechè l'hash del ******* non possa essere simulato con qualche riga
appositamente formata.

Comunque, secondo me, il digitale si presta molto più della carta a
trucchi e spoofing.
Carta canta, diceva qualcuno...
Paolo C. 2 Lug 2016 08:42
Il 01/07/16 23.40, ArchiPit ha scritto:

>
> Giusto.
> Semprechè l'hash del ******* non possa essere simulato con qualche riga
> appositamente formata.

Infatti se leggi l'altro mio post avevo ipotizzato che il ******* con il
progetto dovesse essere un ******* di testo pulito (no pdf, ecc) e che non
dovessero esserci caratteri "nonsense".

Ammesso che si riesca a generare un hash collision, sarebbe impossibile
generare un hash collision con un ******* di testo che contenga frasi in
italiano di senso compiuto....
...mentre con un pdf in teoria sarebbe piu' semplice perché si
potrebbero s*****are a piacimento le parti grafiche.
Andrea D'Amore 2 Lug 2016 10:01
On 2016-07-02 06:42:30 +0000, Paolo C. said:

> Ammesso che si riesca a generare un hash collision, sarebbe impossibile
> generare un hash collision con un ******* di testo che contenga frasi in
> italiano di senso compiuto....
> ...mentre con un pdf in teoria sarebbe piu' semplice perché si
> potrebbero s*****are a piacimento le parti grafiche.

E moltiplicando gli hash, cioè chiedendo ad esempio sia MD5 che SHA1 (o
altri) del ******* originale le possibilità di violare la gara non
diventano praticamente nulle indipendentemente dal tipo di *******

Cioè si consegna ******* criptato e un numero di hash maggiore di un certo
numero N, all'apertura il ******* prodotto deve avere corrispondenza su
tutti gli hash (e ovviamente essere ri-criptabile e diventare uguale al *******
presentato inizialmente) pena l'annullamento.


--
Andrea
Paolo C. 2 Lug 2016 10:39
Il 02/07/16 10.01, Andrea D'Amore ha scritto:
> On 2016-07-02 06:42:30 +0000, Paolo C. said:
>
>> Ammesso che si riesca a generare un hash collision, sarebbe
>> impossibile generare un hash collision con un ******* di testo che
>> contenga frasi in italiano di senso compiuto....
>> ...mentre con un pdf in teoria sarebbe piu' semplice perché si
>> potrebbero s*****are a piacimento le parti grafiche.
>
> E moltiplicando gli hash, cioè chiedendo ad esempio sia MD5 che SHA1 (o
> altri) del ******* originale le possibilità di violare la gara non
> diventano praticamente nulle indipendentemente dal tipo di *******

penso proprio di sì, le probabilità diventano molto vicine a 0,
se poi il ******* originale deve avere un senso compiuto e non una sequenza
di byte pseudorandom, la probabilità è praticamente 0

>
> Cioè si consegna ******* criptato e un numero di hash maggiore di un certo
> numero N, all'apertura il ******* prodotto deve avere corrispondenza su
> tutti gli hash (e ovviamente essere ri-criptabile e diventare uguale al
> ******* presentato inizialmente) pena l'annullamento.
>
>

il problema casomai sarebbe, a livello puramente teorico, se gli altri
concorrenti, prima di consegnare, vedendo l'hash di chi ha già
consegnato, con una potenza di calcolo aliena(*), potrebbero tramite
bruteforce risalire al ******* originale.

Se proprio vogliamo essere paranoici potremmo mettere questo regolamento:
il giorno 1 si spediscono le PEC con l'hash del ******* con l'offerta e
tutti devono spedirla il giorno 1
il giorno 2 si pubblicano sul sito gli hash dei files dei vari concorrenti
il giorno 3 i concorrenti devono inviare il ******* vero e proprio

a questo punto nessuno in teoria puo' vedere l'hash altrui prima di
consegnare. Se poi uno è proprio paranoico invia il proprio hash alle
23.55 del giorno della scadenza, un eventuale impiegato corrotto
nell'amministrazione appaltante non avrebbe tempo di comunicarlo al
concorrente corruttore e quest'ultimo non avrebbe tempo per il bruteforce.

(*) è solo un'ipotesi teorica, se fosse possibile in tempi umani avremmo
trovato il modo di comprimere grandi quantità di dati in stringhe
piccolissime.
Paolo C. 2 Lug 2016 10:41
Il 01/07/16 23.40, ArchiPit ha scritto:

>
> Comunque, secondo me, il digitale si presta molto più della carta a
> trucchi e spoofing.
> Carta canta, diceva qualcuno...

Secondo me è l'opposto, la carta puo' essere sostituita, contraffatta, ecc
Pensa ad esempio ai documenti d'identità, secondo me falsificare una
carta di identità è attualmente piu' facile che falsificare una firma
digitale.

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Discussioni sulla computer security | Tutti i gruppi | it.comp.sicurezza.varie | Notizie e discussioni sicurezza varie | Sicurezza varie Mobile | Servizio di consultazione news.