Armando47

From ciapini
Jump to navigation Jump to search

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
  • ema: aprs

Hardware

Interfaccia utente

keypad

16 tasti: da 0 a 9 e A/su B/giu C/sinistra D/destra E/enter F/exit

  • microswitch in matrice di 4x4: costoso, bisogno di bucare box
  • touch capacitivo: complesso lato SW, tocco meno confortevole

lcd

per una serie di ragioni sarebbe meglio un GLCD (piu modelli a 3.3, piu compatto, piu economico) ma sembra che nessuno voglia prendersi lo sbattimento di implementare una grafica quindi forse, per ora, si va su un display a caratteri

un fet controlla l'accensione della backlight

Contenitore

se il device e' capace di caricarle, volendo si puo fare a meno dello scompartimento batterie apribile. si mettono dentro le batterie e si avvita. piu semplice e compatto, ma si perde la possibilita di poter aver dietro piu batterie e sostituirle.

c'e' poca roba per 4 stilo, volendo si puo andare a 2 o 3 stilo.

possibili candidati


PCB

il circuito stampato + componenti avra spessore minimo (6 mm), e dovrebbe essere abbastanza piccolo (8-10 cm2), al netto di eventuale parte per la tastiera

Connettori esterni

Jack audio

Saranno due jack stereo da 3.5mm. idealmente il pinout dovrebbe essere piu simile possibile a quello degli rtx piu diffusi, in modo da poter collegare le radio con semplici cavi maschio-maschio jack

purtroppo i pinout degli rtx in circolazione sono una giungla. bisogna vedere sopprattutto i tipi di PTT in circolazione. da armando si puo avere sia una tensione per TX che una chiusura contatto.


letture:

Connettore digitale

viene esposta un po di roba attraverso un header con passo 0.1", dual line

GND Massa del device
digital V+ Uscita 3.3v regolati
UART_RX
UART_TX
UART_CTS
UART_RTS
OutSymbolBit0
OutSymbolBit1
OutSymbolBit2
OutSymbolBit3
PTT in
PTT out
SQUELCH in

Connettore alimentazione

se le pile sono 2, il connettore di alimentazione puo essere un mini-USB

Componenti interni

  • processore: dspic33fj128gp802 oppure dsPIC33FJ128GP804 se i piedini non ci bastano
  • 2 regolatori 3.3v
  • quarzo 8mhz
  • quarzo 32khz
  • op-amp filtro antialias 4khz
  • op amp uscita
  • condensatori di livellamento vari
  • condensatore tampone per cambio pile
  • FET di controllo carica batterie

Alimentazione

regolatori

step-up:

charge-pump

power manager:

batterie

4 stilo o ministilo Ni-Mh o alkaline (la tensione va da 4.5 a 6v)

se 4 stilo e' scomodo per altri motivi, si puo andare con 2 stilo e regolatore step-up. di buono c'e' che si puo caricare da usb.

la tensione batteria a monte dei regolatori viene campionata a valle di un partitore 1/2 quando la tensione scende sotto il livello critico, il device va in sleep.

ricarica batterie

il device deve poter ricaricare le batterie da una alimentazione esterna, con controllo dV della carica.

questo significa che l'alimentazione esterna sara' di almeno n_pile*1.27*1.5 = (4 pile = 7.62 v, 2 pile = 3.81v)

tampone

il device deve poter conservare le impostazioni anche dopo brevi interruzioni dell'alimentazione (cambio pile o alimentazione esterna) se il uP e' in sleep mode dovrebbe bastare un condensatore elettrolitico


Protocolli

armando e' in grado di parlare differenti protocolli

APRS

Automatic Packet Reporting System, e' un sistema di localizzazione a pacchetti che usa un protocollo AX.25 in modalita senza connessione su una modulazione afsk Bell 202 a 1200 bps

sarebbero utili 3 modalita APRS

  • client, che riceve dalla UART stringhe NMEA e le trasmette in aprs
  • digipeater, che ritrasmette i messaggi APRS ricevuti
  • gateway, che manda via UART i messaggi APRS ricevuti

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

arNet

Il protocollo di comunicazione specifico di armando e' arNet

e' un protocollo per lo scambio di piccoli blocchi di dati (da 16 a 1024 byte) tra piccoli gruppi di nodi (massimo 256), connessi da un mezzo fisico:

  • half-duplex
  • senza meccanismi di collision detect
  • con rilevazione di canale occupato opzionale

usa schemi di modulazione psk o fsk, con costellazioni di dimensione da 2 a 32.

per resistere agli errori di trasmissione, gli header e i dati passano attraverso un #FEC.

um messagio arNet e' composto da:

diversamente dai sistemi a layer, il trasporto dei dati in arNet viene caratterizzato da delle features liberamente combinabili.

i nodi possono essere terminali o router

il routing si basa su due livelli di indirizzo:

  • un indirizzo del terminale, valido tra i terminali che condividono il canale fisico
  • un indirizzo del segmento, che identifica il canale fisico

Cifratura

algoritmo di cifratura: AES-256 (blocco 128 bit, chiave 256 bit)

la chiave e' composta di 64 caratteri esadecimali

il blocco crittato e' sempre di 16byte

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.

letture:

Interleaver

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 o piu determinate lettere dell'alfabeto in ogni 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.

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

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

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 

uint8_t InterleaveBlock(uint8_t *InData, int16_t *DataMatrix, uint8_t *ModulationSymbolsBuffer){
   uint8_t BitPos, SymbolOffset, BitOffset;
   for (uint8_t FECBlock = 0; FECBlock < HadamardCodesPerInterleaverBlock; FECBlock++){
 
      BlockEncodeChar(DataMatrix, InData[FECBlock]);
      for (uint8_t FECBit = 0; FECBit < HadamardCodeSize; FECBit++){
	 BitPos = (FECBlock * HadamardCodeSize) + FECBit;
	 BitOffset = BitPos % BitsPerModulationSymbol;
	 SymbolOffset = ((FECBit * HadamardCodeSize) + FECBlock) % SymbolsPerInterleaverBlock;
	 ModulationSymbolsBuffer[SymbolOffset] |= (DataMatrix[FECBit] & 0b1) << BitOffset;
	 // printf("%u,%u,%u\n", SymbolOffset, BitOffset, BitPos);
      }
//      printf("\n in FEC: ");
//      printbuf(DataMatrix, HadamardCodeSize, 8);
   }
}

che produce una disposizione [2], dove il colore e' l'ordine dei bit in ingresso (dal blu al rosso), la x e' il tempo e la y il simbolo in uscita

Soft-Decision

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

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

indica l'inizio di una trasmissione. 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. viene usato per la sincronizzazione di simbolo e per l'equalizzazione.

lunghezza 8 simboli. 4 simboli alla frequenza/fase base e 4 all'estremo opposto della costellazione di simboli (frequenza massima/fase +180).

letture:

Blocchi header

sono una serie di almeno 1 blocchi con dimensione sempre 4 bytes che precedono sempre una serie di zero o piu blocchi dati.

il primo blocco e' chiamato default header ed e' sempre presente.

i blocchi header successivi sono indicati dall' header type

i blocchi header subiscono tutti block-coding -> interleaving

la lunghezza dell'intero messaggio sara sempre 4 + (hnum * 4) + (siz * 16) bytes

Default header

e' l'header di base, sta all'inizio di ogni messaggio e si occupa dell'instradamento locale e dell'ordinamento dei pacchetti

8b (src) 8b (dst) 2b (hnum) 6b (siz) 8b (cnt)

campi:

  • hnum numero di header da 4 byte che seguono il default header.
  • siz dimensione del blocco dati che segue in multipli di 16byte
  • src indirizzo del mittente
  • dst indirizzo del destinatario/indirizzo del gruppo destinatario
  • cnt contatore incrementale dei pacchetti inviati dal nodo con tupla (src,dst/grp). un salto nella numerazione implica perdita pacchetti.

il multicast e' semplicemente un indirizzo di ricezione secondario sui client

src e dst sono significativi solo sul canale fisico, e' normale che ci siano client omonimi su due canali diversi

l'indirizzo 0 e' broadcast.

Segment Access Advertisement Header

il pacchetto viene mandato esclusivamente dai router per istruire i terminali che sono nel segmento di rete sul proprio indirizzo globale e sulle regole di accesso al canale

il routing e' un instradamento a livello globale.

un indirizzo globale e' composto dallindirizzo del segmento concatenato collindirizzo del terminale

tutti i terminali sul canale che ricevono il pacchetto e vogliono aderire al router devono memorizzare queste impostazioni

i router presenti sul segmento devono concordare sulle informazioni contenute in questo pacchetto

4b (htype) 8b (tframe) 8b (segaddr)
  • htype tipo header 0x1
  • tframe dimensione timeframe del segmento in multipli di 10msec.
  • segaddr indirizzo del segmento di rete

il tempo di riferimento del segmento viene resettato all'inizio dello start block di ogni SAAH inviato dal router

letture:

https://en.wikipedia.org/wiki/Time-division_multiplexing https://en.wikipedia.org/wiki/Time_division_multiple_access https://en.wikipedia.org/wiki/Dynamic_TDMA#Dynamic_TDMA https://en.wikipedia.org/wiki/Scheduling_algorithm

global routing advertisement header

il pacchetto viene mandato esclusivamente dai router ad altri router per descrivere la topologia della rete

global routing header

viene usato dai nodi per mandare un messaggio a nodi che stanno su un segmento (canale) diverso da quello corrente.

4b (htype) 4b (ttl) 1b (fecn) 1b (becn) 8b (segsrc) 8b (segdst)
  • htype tipo header 0x2
  • ttl numero di hop massimi di routing. viene decrementato ad ogni hop.
  • fecn forward congestion notification. 0 normale, 1 congestionato.
  • becn backward congestion notification. 0 normale, 1 congestionato.
  • segsrc id del segmento di rete del mittente.
  • segdst id del segmento di rete del destinatario.

se segsrc e segdst sono entrambi uguali al segaddr, allora il router funge da repeater

i client ignorano i messaggi con segaddr diverso dal proprio

CRC header

per avere conferma che il messaggio e' stato trasportato senza essere danneggiato

4b (htype) 4b (crctype) 24b (crc)
  • htype tipo header 0x3
  • crctype tipo crc (0x0000 = CRC-24 di OpenPGP)
  • crc valore crc di TUTTO il blocco dati
Transport Reliability header

quando il FEC non basta...

4b (htype) 4b (arqtype) 8b (cnt)
  • htype tipo header 0x4
  • arqtype schema arq: 0x0 = "Stop-and-wait ARQ", 0x1 = "Go-Back-N ARQ", 0x2 = "Selective Repeat ARQ"
  • arqaction arq action (ack, nack, retransmit)
  • arqvalue arq value (cnt, back)

letture:

http://www.isode.com/whitepapers/stanag-5066.html

Blocco DATA

sempre 16 bytes di dati netti

subisce: cifratura -> block-coding -> interleaving

ANI

client e server Push-To-Talk ID e selective calling.

tipi di ANI

  • Motorola’s MDC-1200
  • Kenwood’s FleetSync
  • Harris’ G-Star (aka GE-Star)
  • DTMF
  • 5-Tone

letture:

Firmware

voci di configurazione

  1. modulazione
    1. tipo di modulazione
      1. fsk
        1. bw in Hz uint16
      2. psk
      3. frequenza centrale uint16
      4. dimensione costellazione uint8
      5. simboli per secondo uint8
  2. ptt
    1. manuale/automatico
    2. tempo di guardia attacco in ms uint8
    3. tempo di guardia stacco in ms uint8
  3. protocollo
    1. arNet
      1. indirizzo uint8
      2. alias ricezione uint8
      3. router bool
        1. priorita uint8
        2. ttl uint8
      4. chiave 256 bit
    2. aprs
  4. interfaccia
    1. auto power off
    2. backlight

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 Quarzo 8MHz OSC1
31 Quarzo 8MHz OSC2
32
33
34
35
36
37
38
39 VSS
40 VDD
41
42
43
44


generatore OTP

dato che abbiamo un rtc l'apparato potrebbe fare da one time password generator. usiamo la chiave come seme? che implementazioni ci sono?

letteratura:

stringa di configurazione

la configurazione dell'apparato deovrebbe essere importabile ed esportabile come una stringa esadecimale anche la chiave crittografica sara una stringa di 16 caratteri esadecimali

PIN/PUC

quando il device andra in sleep sara necessario un pin di 4 caratteri per risvegliarlo

dopo 5 tentativi sbagliati, il device dimentica la chiave crittografica.

Retrieved from "http://ciapini.wiki.esiliati.org/index.php?title=Armando47&oldid=253"