Armando47

Device crittografico tascabile

device piccolo ed economico per lo scambio di messagi di testo cifrati su canali audio.

chi e' interessato a una parte se la prenoti

• gnugo: FEC, interleaver, hardware
• ciaby: dds

externals

• keypad 4x4 microswitch
• jack audio in/ptt
• jack audio out
• header 2x5
• jack 5v dc

internals

• processore: dspic33fj128gp802 oppure dsPIC33FJ128GP804 se i piedini non ci bastano
• 2 regolatori 3.3v
• quarzo 8mhz
• op-amp filtro antialias 4khz

lcd

• lcd
  • http://www.ebay.com/itm/1-8-Serial-SPI-Interface-TFT-Color-LCD-Module-Display-128-x-160Dots-/170856821451?pt=LH_DefaultDomain_0&hash=item27c7dc32cb

un fet controlla l'accensione della backlight

batteria

4 stilo (da 4.8 a 6v)

la tensione batteria a monte dei regolatori viene campionata a valle di un partitore 1/2

protocolli

• m-fsk
• m-psk
• aprs: Bell 202 a 1200 bps

Cifratura

algoritmo di cifratura: AES-256

• http://www.literatecode.com/aes256 sembra ok
• http://gladman.plushost.co.uk/oldsite/AES/
• http://axtls.sourceforge.net/

FEC

algoritmo di FEC: Hadamard code

la latenza minima al netto del FEC e' data dal blocco di crittazione (16bytes).

anche la granularita della protezione di errore FEC e' data dal blocco di crittazione (16bytes): e' inutile tentare di preservare l'integrita di blocchi di dati piu piccoli di 128bit, il danneggiamento anche di un solo bit si ripercuoterebbe sul contenuto di tutto il blocco di crittazione.

se si perde anche un solo bit del segnale al netto del FEC vanno persi 16 caratteri.

questo e' tendenzialmente male pensando all'uso con messaggi di testo, i linguaggi naturali hanno una loro ridondanza a livello di parola considerevole. per applicazioni non di testo questo vantaggio non esiste, anche se per messaggi molto piu piccoli di 16byte l'overhead dato dal padding e' comunque considerevole.

d'altra parte dimensioni di blocco crittografico piu piccole implicherebbero minore sicurezza (anche se in realta il tutto sarebbe proporzionale alla quantita di dati trasferiti con una determinata chiave). crittare il codice FEC (n = 128bit, se si usano input k di 8 bit) sembrerebbe allettante dato che si allineerebbe al blocco crittografico, ma:

1. crittograficamente e' un inganno, dato che i codici fec trasmessi sono comunque sempre 256 dal punto di vista della ripetitivita sarebbe equivalente ad usare una cifratura con dimensione blocco di 1byte. troppo poco.
2. dal punto di vista del FEC e' un inganno, decrittando un blocco danneggiato si avrebbe un codice fec danneggiato in maniera complessa, perdendo il vantaggio della ortogonalita del codice di hadamard.

alla luce di questo forse ha senso considerare dei block codes diversi da quello di Hadamrd, che e' non-ottimale per k maggiore di 7 [1].

la dimensione del blocco FEC * numero di caratteri del blocco AES sarebbe quindi:

1. 2^(8-1) * 16 = 2048 bit nel caso di FEC con input a 8 bit.
2. (2 * 2^(4-1)) * 16 = 256 bit nel caso di FEC con input a 4 bit (ogni carattere 2 input).

prendendo il secondo caso, con un alfabeto di 16 toni per simbolo, quindi 4 bit, la latenza sarebbe di 64 simboli, che a 32 simboli per secondo farebbe 2 secondi per 16 caratteri.

la cosa migliore da fare e' rassegnarsi a questa latenza di blocco e cercare di fare uno spreading piu efficiente possibile, vedi interleaving.

indice di affidabilita

nella catena di demodulazione si possono ottenere diversi indici di affidabilita

• rapporto tra il tono di picco e la media degli altri toni
• valore del picco carattere nella trasformata di hadamard

path di trasmissione

i possibili problemi 'descrivibili' del path di trasmissione sono:

problemi di spettro:

• interferenze coerenti (toni sovrapposti a uno dei nostri bin)
• errori della risposta in frequenza (equalizzazione..)

entrambi comportano il danneggamiento sistematico di una determinata lettera del simbolo

problemi nella sequenza di simboli:

• disturbo impulsivo prolungato su tutto lo spettro
• disturbo impulsivo ciclico su tutto lo spettro

che comportano la perdita di piu simboli contigui o la perdita sistematica di un determinato simbolo.

Interleaving

per mitigare questi problemi puo essere conveniente una qualche forma di interleaving sia in tempo che in frequenza.

prendiamo il caso di un blocco da 256 bit formato da 4 sottoblocchi quadrati da 64bit -> 16 simboli*16 toni contenenti ognuno 4 caratteri. sarebbe ottimale anche per eventuali caratteri di controllo.

con un hadamard code, si possono correggere fino ad 1/4 dei bit del codice.

prendiamo come casi peggiori possibili

• la perdita sistematica di 1 bit del simbolo
• la perdita di un intero sottoblocco

questo significa che in ogni sottoblocco si possono danneggiare (non contemporaneamente) fino a:

• 4 simboli
• 4 toni ?

il sistema piu rudimentale e' l'interleaving elicoidale, ad esempio una rotazione nel senso della sequenza combinata con una rotazione nel senso del simbolo. l'incremento sarebbe di un bit/simbolo in senso verticale e di un sottoblocco + un simbolo in senso orizzontale

[2]

Soft-Decision

una cosa MOLTO carina da fare (dato che siamo in uno dei pochi casi in cui le risorse di calcolo sono ben piu grandi della banda) e' avere una qualche strategia di soft-decision pilotata dai valori in uscita dalla fft, magari triggerata da differenze tra l'energia nei bin inferiori a una data soglia.

Blocco START

precede sempre un blocco HEADER questo riferimento deve avere autocorrelazione tendente a zero, essere abbastanza lungo (raro) da evitare false partenze, abbastanza corto da non creare overhead.

lunghezza 8 simboli. 4 simboli che rappresentao bit0 e 4 che rappresentano il bit massimo.

blocco HEADER

dimensione sempre 4 bytes, precede sempre una serie di uno o piu blocchi dati

subisce block-coding -> interleaving

Modalita':

punto-punto (non routed)

1b (cast)

1b (rout)

8b (src)

8b (dst)

6b (siz)

8b (cnt)

punto-punto (routed)

1b (cast)

1b (rout)

8b (src)

8b (dst)

4b (ttl)

1b (prio)

1b(FCN)

8b (seq)

broadcast/multicast (non routed)

1b (cast)

1b (rout)

8b (src)

4b (grp)

4b (flg)

6b (siz)

8b (cnt)

broadcast/multicast (routed)

1b (cast)

1b (rout)

8b (src)

4b (grp)

4b (flg)

4b (ttl)

1b (prio)

1b(FCN)

8b (seq)

campi:

• cast 0 unicast / 1 multicast.
• rout routing. i pacchetti routed hanno dimensione fissa di 1 blocco controllo (4byte) + 1 blocco dati (16byte), i pacchetti non-routed hanno un blocco controllo seguito da 1 a 64 blocchi dati da 16 byte.
• siz dimensione del blocco dati in multipli di 16byte
• src indirizzo del mittente
• dst indirizzo del destinatario
• cnt contatore incrementale dei pacchetti inviati dal nodo con tupla (src,dst/grp). un salto nella numerazione implica perdita pacchetti.
• seq sequenza incrementale dei pacchetti inviati dal nodo con tupla (src,dst/grp). i router e i riceventi riordinano i pacchetti con questo.
• ttl numero di hop massimi di routing. viene decrementato ad ogni hop.
• pri priorita. 0 alta, 1 bassa.
• fcn forward congestion notification. 0 normale, 1 congestionato.
• grp indirizzo del gruppo destinatario
• flg flag ?

Blocco DATA

sempre 16 bytes di dati netti subisce crittazione -> block-coding -> interleaving

connettore digitale

GND

digital V+

UART_RX

UART_TX

UART_CTS

UART_RTS

OutSymbolBit0

OutSymbolBit1

OutSymbolBit2

OutSymbolBit3

PTT in

PTT out

SQUELCH in

voci di configurazione

• modulazione
  • tipo di modulazione
    • fsk
      • bw in Hz uint16
    • psk
    • ook
    • frequenza centrale uint16
  • bit per simbolo (da 1 a 4)
  • simboli per secondo uint8
• ptt
  • manuale/automatico
  • tempo di guardia attacco in ms uint8
  • tempo di guardia stacco in ms uint8
• pacchetto
  • indirizzo uint8
  • gruppo uint8
  • router bool
  • priorita bool
  • ttl uint8
• chiave 256 bit

uC

mappa pin:

Pin	Funzione	Nome	porta
1		MCLR
2	Ingresso audio. sbilanciato 3.3v	AUDIO_IN	RA0
3	Livello batteria/2	BATT_IN	RA1
4	Pulse 1 matrice tasti/PGED1	KEY_PULSE_1	RB0
5	Pulse 2 matrice tasti/PGEC1	KEY_PULSE_2	RB1
6	Pulse 3 matrice tasti	KEY_PULSE_3	RB2
7	Pulse 4 matrice tasti	KEY_PULSE_4	RB3
8		VSS
9	Xtal 8mhz	OSC1	RA2
10	Xtal 8mhz	OSC2	RA3
11	Ptt in	PTT_IN	RB4
12	Ptt out	PTT_OUT	RA4
13		VDD
14			RB5
15	Display SDO		RB6
16	Display SCL		RB7
17	UART Tx		RB8
18	UART Rx		RB9
19		VSS
20		VCAP
21	Ritorno 1 matrice tasti	KEY_RETURN_1	RB10
22	Ritorno 2 matrice tasti	KEY_RETURN_2	RB11
23	Ritorno 3 matrice tasti	KEY_RETURN_3	RB12
24	Ritorno 4 matrice tasti	KEY_RETURN_4	RB13
25	Uscita + DAC	DAC1LP	RB14
26	Uscita - DAC	DAC1LN	RB15
27		AVSS
28		AVDD

Pin	Funzione	Nome	porta
1
2
3
4
5
6		VSS
7		VCAP
8
9
10
11
12
13
14
15
16		AVSS
17		AVDD
18		MCLR
19	Ingresso audio	AUDIO_IN	AN0
20	V batteria/2	VBATT_IN	AN1
21		PGED1
22		PGEC1
23
24
25
26
27
28		VDD
29		VSS
30		OSC1
31		OSC2
32
33
34
35
36
37
38
39		VSS
40		VDD
41
42
43
44

APRS

Qui c'è vita morte e miracoli dell'aprs, con relative specifiche:

http://www.aprs.org/

la prima reference: ftp://ftp.tapr.org/aprssig/aprsspec/spec/aprs101/APRS101.pdf

sw da cui è possibile attingere: http://info.aprs.net/index.php?title=Software

Per fortuna ci sono delle bellissime librerie in c++

http://sourceforge.net/projects/libaprs/

http://sourceforge.net/projects/ax25/

https://code.google.com/p/trackuino/ (solo invio) c'e' una versione in gcc-C

https://sites.google.com/site/ki4mcw/Home/arduino-tnc (solo ricezione)

http://aprsdroid.org/ (invia e riceve, codice utilizzabile?) AGH! e' scritto in SCALA.. mi sa di no