1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
Protokoll:
self made downlink protokoll:
* intelligenter Image Dump
* Audio Memory Dump
* Image Bewertungs Index Dump
* Telemetrie und Counter Dump
* random Text-Message Dump (wenn Power da ist)
encapsulated in:
* CCSDSC Frames
GMSK (braucht ~10kHz Bandbreite)
* BPSK 1000 (QPSK 500)
* Turbo-Codec (if licencse allowed)
Reed-Solomon
alt:
* Nix, raw data via FSK31 (or hither)
* Turbo-Phi-Code
* FX.25
* AX.25
(depends on content and configuration Flags)
Frame:
Option 1:
GMSK(CCSDSC(Data,Reed-Solomon))
Option 2:
GMSK(CCSDSC(TurboCode(Data)))
Option 3:
BPSK500(CCSDSC(TurboCode(Data)))
Option 4:
BPSK500(CCSDSC(Data,Reed-Solomon))
...
Protokoll:
Downlink:
+--------------------+-----------------+-------+
| Data Frame Type ID | Frame Type Data | CRC32 |
+--------------------+-----------------+-------+
Downlink Frame Types (Frame Type Data):
* Memory Area Dump Start (new DumpID (inc) , from Address)
* Random Text Message Start (new DumpID)
* Image Data Start Frame (new DumpID, Image ID, from Offset)
* DataDump (current DumpID, Packet ID, Data Length, Data))
* Image Metadata Single Frame (Image ID, file size, Quality Factor, DCT-Coefficients Mean, DCT-Coefficients StdDev, simplified rgb image historgram [3 colours * 64 division * 8 Bytes])
DataDump (current DumpID, Packet ID, Data Length, Data))
Image Metadata Single Frame\\(Image ID, Quality Factor, DCT-Coefficients Mean, DCT-Coefficients StdDev, simplified historgram)
Note:
new DumpId with every "Start"-type frame. Only HARD requirement: dumpid must be different from previous dumpId
PacketID increments with every frame and resets to 0 with "Start"-type frame
DumpId ensures that DataDump streams can be differentiated if in-between StartFrame goes missing
most errors should be corrected by FEC
if Recieve Error of Frame still happens:
* rerequest memory area with offset
* rerequest ImageID (w/offset)
* rerequest whole Dump by explicitly repeating command (can't request dumpid since they are not meant to be uniqe)
Uplink Todo ??
?? ability to resend commands in queue before execute -> QueueSlots and "Insert Command into QueueSlot#" instead of "Append Command"
contra argument: fading signal will propably wane slower than it takes to fill command queue. so sending full command queue multiple times is
more likely to succeed than sending single commands multiple times.
Uplink Commands:
* Clear Command Queue
* Append Command WriteConfigArea (Data, CRC32)
* Append Command DumpMemoryArea (StartAddress, Length)
* Append Command WriteMemoryArea (StartAddress, Length, Data, CRC32)
* Append Command AppendNewTextMessage (Length, Data, CRC32)
* Append Command GetImageMetaData (from ImageID, NumImages)
* Append Command GetImage (ImageID, fromOffset, max Data to transmit or 0 for all data)
* Append Command Send Random Text Message
* Append Command WaitDuration and switch off transciever (Seconds)
* Append Command WaitUntil and switch of Transc (TimeOfDay)
* Execute Command Queue (Num Commands, ExecSeqNum, MAC(Full CmdQueue Contents incl Data . Num Commands . ExecSeqNum))
Note:
Password should be random and 160 bit long
MAC(x) = sha1(password . sha1(x . password))
Satellite keeps track of highest last used ExecSeqNum and rejects lower
Stored ExecSeqNum get's reset to 0 on CRX Reset-Settings
single commands usually don't carry CRC checks, because they are only ever executed as a whole cmd queue.
so it's enough to have integrity check in the last cmd. This also saves bandwidth.
As a side effect, the amound of uplink data to be integrity checked becomes dynamic (i.e. on bad link, just send less commands at once)
To Consider:
maybe CRC32 SHOULD be added to every Clear/Append command, and every append command should be ack in TTX,
so it can be resend on transmission error and execute command has then higher chance of succeeding ?
downside: uplink would be much much slower if (optional) we wait for TTX Acks
upside: execute command has higher chance of executing
Never: substitute sha1 of individual crc32 with sha1 of whole contents in execute command
Attacks:
Substitution Attack:
should not be possible since MAC is calculated over full CmdQueue contents
Repeat Attack:
should be hard, because Nonces are not reusable, unlesss attacker also manages to reset cpu via dtmf
Man-In-The-Middle Attack:
no two way handshake, so no better than other attacks
Brute Force:
can capture uplink stream and brute fore password at home
thus password should utilize full bit range and be sufficiently long e.g. 32 byte random number
Denial Of Service:
If password cracked, nonces can be used up
Uplink Channel can be actively jammed
Append Command can be inserted after our ClearCmdQueue, making sure ExecuteCmd won't suceed
To Consider:
Does Arm Cortex M3 have enough speed/power for RSA | DSA | ECC-DSA ?
|
