From 0f6c3e99ef87a5888a13f9fd578813950370f918 Mon Sep 17 00:00:00 2001 From: Bernhard Tittelbach Date: Tue, 23 Aug 2011 23:41:22 +0000 Subject: ground-rxtx / linkbudget git-svn-id: https://svn.spreadspace.org/mur.sat@150 7de4ea59-55d0-425e-a1af-a3118ea81d4c --- doc/protocols/ground-rxtx.txt | 134 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 134 insertions(+) create mode 100644 doc/protocols/ground-rxtx.txt (limited to 'doc/protocols') diff --git a/doc/protocols/ground-rxtx.txt b/doc/protocols/ground-rxtx.txt new file mode 100644 index 0000000..58c3212 --- /dev/null +++ b/doc/protocols/ground-rxtx.txt @@ -0,0 +1,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 ? + + -- cgit v1.2.3