HEKTOR 128 - Voice encryptor,
based on (very) complex time domain scrambling
The basic idea of this project is to achieve
some pretty high level of voice security just by intensive use of time
domain scrambling in combination with a frequency variation scheme.
These are so-called analogue techniques, that do not alter the
required bandwidth, thus can be inserted to almost any voice channel,
whether analog or digital.
Project overview |
Implementation |
Hardware |
Software |
Testing |
Operation |
Spectrograms |
Index
Pic 1a: Yet another analog voice
scrambler...
Table 1: Features
HEKTOR-Firmware V1.0
|
General
description: |
Complex analog voice encryption,
robust security level, independent,
autonomous and transparent hardware solution
|
| Method(s): |
Time-domain-scrambling and
frequency variation overlay
|
Bandwidth:
|
Telephony / voice
(300...3300 Hz max.)
|
Internal Codec:
|
Deltamodulation (non-adaptive),
average sampling rate about 96 kHz
|
| Blocklength: |
1,28 s + 40 ms
(synchro) |
Blockdivision:
|
128 symbols per block,
(64 frequency variations per symbol) |
Symbol duration:
|
10 ms
(average, speed variation +/- 50 %) |
Key-
management: |
16-digits decimal number
(as a symmetrical session key) |
Keyspace:
|
1016 initial
keys (53-bit binary key)
|
Rolling code scheme:
|
Transtable-change every
block,
Freqtable-change every transit |
| Synchronisation: |
1510 Hz transit preamble
(1,3 s)
1625 Hz block synchro (40 ms)
1625 Hz end-of-block (~ 2 s) |
|
Codename: "HEKTOR"
It is the thesis of this project, that "time domain scrambling" will
effectively compensate most redundancy in the human voice signal, when
it is operated with long blocks and fine
partition and a key generation scheme that produces good
transposition tables of higher entropy changing for every transposition
block.
By this, the resulting analog signal should have build up enough
cryptographical complexity to provide strong tactical security, even
inspite of a serious attacker's signal- and crypto-analytical
capabilities.
Since analogue techniques of voice veiling/scrambling usually do not
require more bandwidth than unencrypted speech, they could be retrofit
to most narrowband voice media, whether analog or digital. On that
score, analog encryption has clear strategic advantages over most of those
all-digital or even IP-based voice crypto solutions (e.g. "VoIP-Sec", "ZFone",
etc.). They always produce higher infrastructural requirements; for special
hardware/software, for a stable internet-connection or at least some
guaranteed bandwidth over ISDN or UMTS; the known vulnerabilities
of PC-based networking applications still remain; and worst of
all, there's still some crap of commercial stuff that's not fully
documented, so it's basically "security by obscurity" - just out of the question!
The proposed hardware consists of a standard
AVR-microcontroller with some decent
RAM-extension and only a few analog components around.
This constitutes for an autonomous, transparent, experimention-friendly
and inexpensive platform.
The proposed software for the microcontroller calculates
transposition ciphers, digitizes the voice waveform, keeps exact timing
in sync, and, of course, it performes this complex variant of time transposition
ciphering with large blocks and a very high "chopping" frequency. All is open
sourcecode, of course!
Key management
In the current configuration, HEKTOR is setup as a
classic symmetrical cryptosystem whoose
initial keys are decimal numbers of up to 16 digits.
Keys are entered directly into a keypad located on the device.
No smartcards nor other external media stuff. These decimal numbers
should
be still memorable - and this allows for the users to keep all
key-management duties in a transparent, conservative, conspirative and
most paranoid manner...!
With 16 decimal places we have nearly 10^16 different
starting conditions (10 quadrillions) of possible keys for this
cryptosystem. In binary notation this would be about
53 bits of keyspace. While the attack on such a complex analog
encryption will always bind some significant computational capacity
for signalanalysis, this keyspace seems sufficient for more than just
tactical security.
Cryptographical strength
In this project, we even set up 128 positions for the
block partition. This will actually provide a very huge
subset of applicable cryptographic keys (i.e. tables that ensure
most random-like mixing of the signal wavelets). The
amount of applicable keys should render any approach of exhaustive
(brute-force) attacking futile by any means. It is further supposed
that other conceivable attacking strategies (based on signal-analytical
or phonetic approach) were too expensive and time-consuming for most
scenarios.
Of course, the transposition table changes with every block. Of
course, the key generation scheme was designed for good pseudorandom
characteristics, and, of course we have not yet implemented any
backdoors :-)
Additionally some frequency variation is applied in the proposed
system. Admittedly, this would not even be much stronger than
"frequency inversion" as a standalone method - but this is not the
point. In combination with a time transposition cipher, we will benefit
from the frequency variation's ability to "blur" the remaining
frequency components that could have passed through
the time transposition. This will surely make any phonetic approach
of signalanalysis even harder. As a positive side effect of the
frequency variation component, the spread audio spectrum gains more robustness against
in-channel-disturbance.
Besides, the naming "HEKTOR" is no far-fetched
acronyme; it's just the greek prefix "hekto" (which means "a hundred")
with a fancy "R" attached, not only for artistic purposes but also to
express
the radical application of transposition with some quite rapid
symbol rate
of approximately 100 transpositions per second. (See Table 1 on top of this
page for the other parameters.)
Drawbacks: That time transposition system represents some unusually
high requirements regarding the medium-term timing
accuracy on the communications channel. On the other hand, these
requirements for frequency response and timing accuracy are still in the
range of ITU-standards (let's hope, these standards will not be further
levelled down in the future). And there has been lots of considerations
and
testing to find an idiot-proof synchronisation method. There may be
further problems arising with very poor analog channels and digital
channels that use rapid compression, like GSM, and likely some
VoIP-Codecs.
Application
All encrypted communication starts as
an unencrypted
call using the regular telephone set. After consultation, both
participants can power up their encryptors to enter the respective
session key. Without muttering. In the next step, both parties agree to
go "confidential mode" and activate their encryptor devices.
Now both participants must change to the microphone and the headphones
of the encryptor device instead of the telephone's receiver.
This is because the encryptor will completely take over the line and fully disconnect the
phone. Changing to a completely different device for encrypted
communication is always recommended. It allows to make a clear
separation between the crypto-device and the normal hardware that is normally used for
public communication and that is deemed unsafe, as is could be "buggy".
For the encryption equipment, technical manipulations may be prevented
more strictly, e.g. keeping this equipment locked away, equipping it
with blasting caps (More phantasy, better than more technology!).
Due to the intermediate storage of speech (once in the transceiving
device, once in the receiving device) and because
there is additional synchronisation needed, the signal
delay accumulates up to 2.6 seconds in the proposed system. Of
course,
this is slightly too
much for
"full-duplex" communication; but it seems still practicable in
half-duplex. This is why the system has been generally designed only
for half-duplex operation, with regard to its compatibility with normal
voice radio applications, too.
This hardware version
The project has been first time published in [10], while the mentioned
article suggested some
two-piece structure for the encryptor, one motherboard with a
standardised contact terminal for the connection of
different interface circuitry (for telephone systems, different radios
etc.). Well , this "modular" approach was intended to facilitate
experimentation with custom-made interfacing circuits to several
radios. Unfortunately, there is still no universal HEKTOR-Radio-Interface
available, and my personal activities got a
little stuck with that...
However, a simple and reliable
circuit for coupling to some telephone line, the HEKTOR LINE INTERFACE,
already exists. Now I have recently conceived the HEKTOR KOMPAKTVERSION
with integrated line interface. This version is limited to telephone
applications, but everything fits on only one PCB of only 75 x 100
mm now.
All functions of this "HEKTOR-Kompaktversion" are identical to the
dyadic variant of HEKTOR-motherboard and HEKTOR-LINE
interface. In particular, the current software/firmware is (and should
be
further on), still the same for both versions.
Up
 |
Picture 1b:
HEKTOR-kompakt
(POTS-only)
|
Technical implementation
With today's electronic components, anybody could make a time domain
scrambling device that can do some amazingly complex
transposition
schemes and calculate very good symmetric ciphers.
The present
hardware platform consists of an AVR-microcontroller,
the ATmega8515 with added SRAM memory, and a programme that
does the
entire flow control, procures key computation, voice sampling and
storage.
Besides, the voice signal is not being digitized by means of some
internal A/D converter of the AVR, just because - the ATMega8515 doesn't have one!
But with his on-chip analog-comparator, he is in fact capable of doing
some analog-digital-conversion due to the principles of "deltamodulation".
(In the course of further project development, it turned out, that this
deltamodulation has been a very good choice, not only because of its simplicity,
but also because of some other favourable characteristics regarding signal
quality and spectral properties.)
If we consider, that, for telephony purposes, one needs a
delta-samplingrate of at least 64 kilobits, with this bitrate we could even store about 4 seconds of
speech in a simple 256k-RAM. This is the right dimension for this kind of
application.
A very pleasant feature of the ATmega8515 (among other AVRs) is his
ability to almost directly address parallel SRAM-circuits with his
parallel
16-Bit-addressbus and 8-bit-databus. The 62256 is such an inexpensive
and robust SRAM-chip. (Hint: If you have
some fast 61256 SRAMs
on stock, these would also be fine with an adaptor-socket.)
As a further component, there's only one 74HC573 latch register
needed for address/data-multiplexing. That's all. All timing and signal
sequencing stuff is being administered to 100% by the processor core of
the mighty ATmega8515. With this support, even ...say, moderate... programmers
(like me) are able to easily address and utilize the vaste address room of
32 KB (or even 64 KB).
Most analog components are needed for convenient signal coupling to the
telephone network and to some headset. The coupling between voice
encryptor and telephone system is done by means of an audio transformer that is
switched directly into the line current, while the ordinary
telephone is simultaneously disconnected. (Basically this is the same way,
analog modems or some answering machines take over the line.)
Why not inserting the voice encryptor into the
handset-telephone-connection cord?
Well, this would
not be a good idea from my point of view! First of all, the handset of
a conventional telephone has always been some popular location for "bugs",
because an eavesdropper would easily bypass any further encryption and
will already get all spoken contents of a phone call served on a plate -
in plaintext. Second point is, it ain't that simple to insert the
encrytion device between telephone and handset, just because the interconnection between
receiver and telephone is not standardized!!! Even the
impedances of speakers and microphones are not necessarily uniform,
so it would be lots of hassle to build a matchbox or some adaptor for
the insertion of an analog encryptor in this place.
On the other hand, the electrical parameters of POTS line terminals are
quite similar in every corner of the world; regarding
loop current, ringer frequency and current, overall frequency response, dial tones. This is why we
came to the conclusion, that the most universal, most
compatible option for analog phone-crypto-coupling would be to
simply occupy the line and throw the conventional telephone off.
However, in Central Europe you
will most likely need a different cable/plug for any european country.
Very strange. Just have a look at this
horrifying overview on current telephone jacks: http://www.holzinger.cc/phone/telefonstecker.htm
Cost: The cost of this project with all accessories may be easily
held under 100 Euros.
Up
Circuit documents: HEKTOR-kompakt Version 1.0
1. HEKTOR-kompakt
v1.0 (left click to enlarge, right click to "save as")
|

|
| 2. Components list
HEKTOR-kompakt version V1.0 |
------------------------------------
Stückliste HEKTOR VOICE ENCRYPTOR
Kompaktversion für Telefonbetrieb
Version 1.00
------------------------------------
05/2008 Julien Thomas, Kiel
------------------------------------
Widerstände:
R1 100k
R2-R8 470
R9-R12 330
R13, R14 1k0
R15, R16 22k
R17 220k
R18 470k
R19 22k
R20 100
R21 15k
R22 22k
R23-R27 10k
R28 100
R29 47k
R30 100k
R31 470
Kondensatoren:
C1-C5 100nF Kerko
C6 10nF Kerko
C7 100nF Folie (MKS)
C8 100pF Kerko
C9, C10 470nF Folie (MKS)
C11 1µF/10V Elko
C12 22nF Kerko
C13 22µF/10V Elko
C14 220nF Folie (MKS)
C15, C16 22p Kerko, NPO
C17 47µF/10V Elko
C18 47µF/25V Elko
C19 100nF Folie (MKS)
C20 1nF Kerko
Halbleiter:
VR1 7805
D1 1N4001
D2 1N4148
T1-T3 BC547C
T4 BC337-25
IC1 AVR AT90S8515-16 oder
ATMEGA8515-16 PDIP
IC2 74HC(T)573
IC3 SRAM 62256 - 80ns
IC4 CMOS 4053
LED1 LED rot
LED2 LED gelb
LED3 LED grün
LED4 LED grün (alle LED Standard
oder
Low Current)
Sonstiges:
- IC-Fassungen für IC1-IC4
- Schwingquarz 10 MHz RM5 (HC18)
- Tastatur Matrix 3x4 (z.B. Conrad Bestnr. 709840, ggf. passenden
Rahmen mitbestellen)
- Stiftleisten/Platinenstecker-Kombinationen für X1-X5
- 2x5 pol. Wannenstecker für X6 (ISP)
- Steckverbindungen zum Anschluss der LEDs
- Platine nach Layout 75 x 100 mm
- NF-Übertrager für Telefonanwendungen,
Übertragungsverhältnis 1:1 bis
1:5
DER GLEICHSTROMWIDERSTAND AUF DER HOCHOHMIGEN SEITE (a/b)
MUSS MINDESTENS 100 OHM BETRAGEN.
(z.B. Conrad NTE-1 515940, Conrad NF-Uebertrager 515701)
- Re1 - 5V/6V DIL-Relais 2fach Umschalter, Spulenwiderstand mind. 90
Ohm, z.B. von Reichelt:
Fin30.22.9 6V (Finder), RY05 W-K (Takamisawa)
- Modular-Einbaubuchse RJ11 6-polig, z.B. von Reichelt: MEB6-6
für TAE-N-Kabel mit RJ11-Stecker auf der anderen Seite,
z.B. von
Reichelt: TAE 4NWS-I
|
|
3. HEKTOR-kompakt
Version V1.0, PCB, single-sided, 300dpi, 75 x 100 mm (right click for
download)
|
|
Circuit details: HEKTOR-kompakt Version 1.0
General
This circuit needs stabilized 5 Volts ("TTL") to be delivered by standard 7805
linear voltage regulator (VR1). The current consumption in ready state is
below 60 mA. The main portion of this current is due to the LEDs and
audio-amplifier. In encryption mode, there's an additional current
of about 30mA for the line relay. The overall current consumption may
be about 100mA while active encryption is running.
The 1A-type of 7805 can still handle this without extra heatsink
necessary, provided, that we do not supply more than 9V of input
voltage.
Crypto Machine
The main actor is an AVR-microcontroller ATmega8515 (IC1). To
describe its peripheral circuitry, we go clockwise around the chip -
see circuit plan for further reference:
PORT A
The lines PA0-PA7 are used as 8-bit address and data bus.
In their function as address lines they go directly to the Latch IC2,
and to read and write SRAM bytes, they are directly connected to the
datalines D0-D7 of IC3.
PORT E
The output line PE0 delivers some PTT-signal, with HIGH for
transceiving mode or encryption, LOW for receiving mode or decryption.
The current that can be delivered by AVR internal port drivers is
sufficient to drive the Rx/Tx-LED and some further logic inputs.
The output line PE1 in its function as ADDRESS Latch Enable (ALE)
controls the address/data multiplexing by the latch IC2 (74HC573).
The line PE2 is configuered as output, too. It supplies a logic signal
for to change between transparency
mode and active encryption mode. HIGH voltage level on PE2 corresponds
to
crypto-mode, LOW means transparent mode. This signal is needed by the
telephone line interface to automatically energize the line-relay Re1
that manages the instant switch-over between conventional telephone and
crypto-devide.
PORT C
This port supplies further 8 address lines, from which
however only 7 are
used. Together with PA0-PA7 the lines PC0-PC6 constitute for a 15-bits
address bus to access the whole memory allocations of the 32-KB-SRAM
IC3.
PORT D
The microcontroller co-ordinates all write and read cycles on the SRAM
directly by the control lines PD6 and PD7 (as /WR and /RD).
PD2 only drives the control LED2 to indicate a sync state or sync
pulses.
PD3 is the input for sychronisation signal, that has been amplified and
delimited by T1 which nearly provides square wave TTL-levels when
synchro-tones are coming in via AUDIO-IN.
PD4 is comfiguered as an output line. In conjunction with R22 and C9 is
builds a low-pass for the delta-feedback-loop for the AVR-internal
comparator circuit with PB3 as the non-inverting input (AIN1).
Reference value for the delta modulator is the audio input signal,
that is made DC-free by C14 and loaded with a constant voltage offset
by R15/R16 over C14 onto the inverting comparator input, PB2
(AIN0).
Last, the output PD5 provides the delta-output signal (delta bit
stream) to feed some similarly dimensioned lowpass (R23, C10) with
a backend buffer, consisting of T2 and its peripheral parts. This
signal is passed over the coupling capacitor C13 (47µF) for
connection
of
telephone.
PORT B
PB0,1,2 and
PB4,5,6 are used for matrix-scanning of the attached 3x4-keypad.
Further, as mentioned above, the lines PB2/PB3 are also used as
comparator inputs (AIN0/AIN1)
for the delta-ADC. Beyond that, PB5/PB6/PB7 can still be used in their
function as an ISP interface
(MOSI/MISO/SCK) to enable flash reprogramming of the µC over the
ATMEL-specified 10-pin ISP connector X6.
Telephone Line Interface
As long as the encryptor is not powered up or it remains in
"transparent" mode, the line pair a/b remains untouched and will be
forwarded by the line relay Re1 to a'/b' and thus forwarded to the
telephone. Just when the encryptor switches into the active crypto
mode, the
controller rises its control line "active/transparent" (PE2) to
HIGH-level. This will drive the transistor T4 to energize the Re1. Now
the LINE relay tightens,
cuts off the telephone line path and puts his own audio transducer
(Tr1) on the line. By its internal
impedance of about 100 to 300 ohms it will hold up the current loop and
keep the connection.
NOTE: The
higher impedance side should be on the side of the telephone
network. Switching time is less than 0.1 s, which is normally too fast
for losing the connection. With the transformer on the line, the device
can now safely r transmit and receive audio signals to and from the
telephone system.
A CMOS triple analog switch (IC4, type 4053) is doing all the
switching of signal directions from the controller to the
transformer and to headphone and microphone as well. The Mic signal of
an elektret cap (e.g. in the headset) has to be preamplified by the factor
of 10, this is done by the simple amplifier stage consisting of T3.
In the parts list some audio transformers are indicated that have
alredy been successfully tested in this application.
Note: Audio levels and transformers transmision ratio aren't that
critical. The
synchronisation scheme will work in a wide range of signal levels.
Both, the delta modulation and the codecs normally used in
analog/digital conversion used in telephone networks permit greater
tolerances. Too high levels are always limited.
Up
Terminal connectors on HEKTOR-kompakt PCB
X1
|
Unstabilized DC from 6 to 9 Volts,
max. allowable current 250 mA.
Voltage should come from a well filtered power supply or batteries. |
X2
|
Connection for 3 colums / 4 rows
matrix keypad.
|
X3
|
Analogue POTS terminal.
Should be
connected to the telephone system by means of a modem-cable (4
lines, a/b and a'/b').
|
X4
|
Direct connectivity for electronic
microphone (e.g. Headset).
|
X5
|
Direct headphone connector, preferably
higher
impedance type for voice application, e.g. headphone of a PC-headset. |
X6
|
This is the ISP-connector in accordance
with
ATMEL-specs. |
LED
1-4 |
These are four 2-pin-connectors for direct
connection of normal LEDs. |
Up
Testing
There's an elementary testing mode available.
It can be
activated by pressing the "#"-key directly after the device
has been powered up or reset by hardware.
In this testing mode, the program will
go directly into an infinite loop,
running the interrupt routine with medium speed adjustment and
continuously generating the blockstart-signal of about 1.5 kHz.
The
signal is generated out of the SRAM with constant reading rate to
allow for easy monitoring of the memory
access cycles. In this testing more, the signal direction is
fixed to "receive/decrypt" mode, so the line relay will not switch on
and the 1.5-kHz-tone will be forwarded
directly to the headset, thus enabling a qualitative assessment of some basic
functions: This tone should have a smooth and stable character with no vibrato
audible (no hard rectangle, rather
triangle-style, few
distortions).
Signals to measure in this testing mode
- Scope or frequency counter on pin 15 of the µC (this
is PD5, the deltamodulation-out pin): in testing mode, there should be
square wave of 50:50% duty cycle with TTL-levels at a frequency of 1510
Hz
- Unloaded Audio-OUT (after C13) should provide the amplified
and smoothened audiosignal with triangle-waveform and a level of about
2Vpp
- On the pins 16/17 of the µC (PD6/PD7) some
clocking/controlling signals with sharp pulses will occur. These
identify the access on the external SRAM which recurrs in a frequency
of 12080 Hz
auf. (Remark: All frequencies refer to the current program version
1.0b.)
If that's o.k., we already proven that: the firmware has been flashed
correctly into the chip and is running; The clock-source has been
correctly setup and
is running with the external 10-MHz-chrystal (otherwise the frequencies
would be much lower); the audio driver and signal switching works
correctly that far. Well done!
Actually testing the encryption- and decryption functionalities
Now we would surely like to test encryption and decryption
and just listen to how it sounds. There's no second device needed for
that test. All you need is a means of recording and playback to
store some selfmade encryted transmission. With an old dictaphone or a
poor cassette recorder it might go
wrong because of instable speed (flutter).
With a good cassette-deck or any PC-soundcard, record and playback of a
HEKTOR-transmission should work without a problem.
Also level conditions concerning
the audio signal are not very critical. Yet it is of highest importance
that the soundcard can record continuously without timing problems. At
a PC we
should
close all other windows and terminate competitive processes.
Recording encrypted test-transmission: Forward the signal
a/b (from X3-2 and X3-3) directly on a
LINE-IN of the soundcard or given recorder. Polarity is unimportant.
Now start the encryptor with a simple key (how about * 0 #
...) and wait until the yellow "Sync"-LED lights up permanently. Start
the recording. Now put on the headset, press the key "0" and say
something eventful. Release the "0" / "PTT" button after some seconds
of 10 to 30 seconds of speaking. Wait some seconds for the
block-end-synchro to be sent completely. Stop the recording.
Playback encrypted test-transmission: Now connect the
signal path a/b (from X3-2 and X3-3) to the speaker/headphone output of
the soundcard. Before playback you must reset the encryptor and reenter
the same code as before. (Otherwise you
will not even recognize your own voice.) Now put on the headset, start
playback from the PC/other audiodevice and listen!
For a one-way-testing, the ZIP in the FA-Download-Section
offers some audio files, that should be compatible with the current
software (and perhaps with following versions). These were
intentionally to a compareably bad telephone quality (only 8k-sampkes).
It should be demonstrated, that the decryption procedure will even
synchronize under pretty poor conditions. These examples are
decryptable with the standard code of * 0 # .
Up
Operation
Table 2: Operational states of "HEKTOR-128 analogue voice
encryptor, software version 1.x
| STATUS
|
Options
|
LED1
Trans
|
LED2
Sync
|
LED3
Rx
|
LED4
Tx
|
Headphone,
speaker
|
| testing
mode |
Switch
on,
press #
|
lights
|
off
|
lights
|
off
|
continuous
tone |
transparent
(passive)
|
Restart
with *
|
lights
|
off
|
lights
|
off
|
starting
tone
(three beeps)
|
| key
input |
Start
with *,
Input max. 16 digits,
confirm with #
|
lights
|
off
|
lights
|
off
|
confirmation
tones
for keypress
|
Ready,
Standby
|
Press 0
to talk,
Restart with *, |
off
|
lights
|
lights
|
off
|
nothing |
Receive
(decrypt)
|
Back to
Standby with #
Restart with * |
off
|
flashes
|
lights
|
off
|
other
station
|
Transmit
(encrypt) |
Press and
hold "0"
Restart with * |
off
|
flashes
|
off
|
lights |
nothing
|
Synchronisation
The method of block
synchronisation has proven amazingly reliable. The system resynchs
with every new block. But even if one or more block synchros were
"loosen" by signal jamming or other interference, the system will
recover in most cases when the next sync returns. In the meantime, the
receiver's device is
"running free" with the precision of its own clock generator, which
allows to overcome at least two or three blocks of disturbed signal.
Even if one complete transit has become illegible, there is no need to
give up and restart, since both devices will start the next transit
with one common table. (See the well commented sourcecode on how the trick is done.)
Just to add, this method of synchronisation and this kind of key
generation (all devices use the same transposition table at the same
time), likely allows more than just two parties for encrypted voice
communication. Yet, it hasn't been comprehensively tested now, but it
should also work in a telephone conference or a QSO round. To avoid
collision, it may be a good idea to strictly determine some sequencing rules
on which participant is allowed to transmit at a time.
Key agreement
Since it concerns a
classical symmetrical cryptosystem, of course the old problem of the
key agreement emerges. For this we surely need a safe communication way
at
least once to exchange the keys or to negotiate some kind of
key-generation rule.
Well, if we use internet and email, this shouldn't be real problem
anymore. How about PGP or some good (!) stegano-tool? Being lazy, all
further keys may be exchanged directly via encrypted voice
communication then.
Key management
Maybe some people are not willing to keep some plain 16-digits-numbers
in their head. Maybe it's sufficient to just generate new session keys
by simply combining some 8-digits secret key plus actual date - like
this:
Secret key: 12345678
Date: 20080601
Session key: *1234567820080601#
Hardware Security
A crypto-hardware that already works with memorable keys, should
consequently "forget" all key-related information in the moment it is
switched off. No permanent storage of keys in the EEPROM of the
controller or external smart cards.
Such hardware may be used by everyone safely, without leaving sensible
information in the device after it has been reset or
detached from the power supply. The same applies, if the machine should
get "lost" (stolen).
Up
Firmware
Software
The whole program has been prepared and compiled under the comfortable
GUI of BASCOM AVR. The HEKTOR-firmware mainly consists of assembler
routines, that are administered by some uncritical BASIC-structures.
This has been the only way to implement that highspeed delta-interrupt
and some really fast transposition key calculation. It is also owed to
the high portion of machine
code, that this program can be compiled with the demo version
of Bascom AVR which is limited to 2 KB of programme code :-)
The source code is well commented, so it should be easy to understand
the programming en detail.
Download
The stable version is available in the download section of [10].
Firmware is identical for the "classic" HEKTOR-version of 2 PCBs and
the Kompaktversion suggested in here.
Flash programming
Of course there are precompiled binaries available for direct flashing.
To program the AVR with AVR-OSP,
AVRprog or TwinAVR, binary or Hex files are provided. Please note, that
on delivery, the fusebits of a new AVR are normally set to use internal
RC-oscillator as the clock source. These bits must be modified anyway
to use the external chrystal. I however recommend to set the
fusebits at first, because this would be the most critical moment.
Fusebit-pitfalls
Picture to the right shows the fusebits in the representation of
TwinAVR, as they must be set to configure the AVR to use external
10-MHz
chrystal for clock generation. As a difference to the basic state of
the chip, the CLKSEL0 is now set, which however means under
TwinAVR, the checkmark has
to be clicked away.
Additionally CLKSEL2 and CLKSEL3 must be unset to activate
external chrystal - this means, these fields must be checked now.
In particular, one should refrain from the funny idea of
only
setting CLKSEL0 without clearing CLKSEL2
and CLKSEL3 simultaneously - as this will leave the AVR without
any clock source - and in this state it wouldn't even respond to serial
ISP/SPI anymore. (But that's not so serious: The chip is not broken. It
will respond again, if we connect some external clocksource of
e.g. 1 MHz to the pin XTAL1.)
Up
Spectrograms

|
Illustrative
Spectrogram* 1:
Female speech, unmodified,
5 seconds.
*) This and the following transformation were generated
with the
software spectrogram [6].
|
|
|

|
Illustrative
Spectrogram 2:
Female speech, HEKTOR-128-
encrypted,
about 5 seconds,
3 blocks
The lines before and after the transmission are the
pure start (~1500 Hz) and stopp (~1625 Hz)
synchronisation carriers. The bursts for block
synchronization
appear as bright points in a distance of 1.3 seconds.
|
Up
Remarks
A transparent, diy and open-source device for secured
speech communication over analog telephone systems or voice radio has
been
suggested.
The proposed system makes intensive use of time transposition ("time
domain
scrambling") as an analog encryption technology that is easily to be
applied on many different voice channels.
The project is and should ever be "Open Source". The author does not
state, that the presented software and hardware will be an
ultimative platform for analog voice encryption. In fact, it is just a
problem-oriented suggestion. If someone feels encouraged to submit a
better approach, then he or she should publish this alternative
solution under similar conditions, at least "open
source"!
PCBs, kits or even ready-made devices may be delivered by the author,
but only by the piece and strictly on a P2P-basis.
Up
|