Portable Encoding Unit

I received some of the parts I need for developing the prototype of the PEU. I have the display, the key buttons and a proto pcb. I've soldered these parts together and here's a picture.

For the prototype, I'll probably use a separate board of the same type to mount the Teensy 3.6 main processor and the code module. In a final design, I'm planning on laying out a PCB using mostly surface-mount parts with the Teensy 3.6 and code module mounting on the back-side behind the display.

Here's a realistic 3D printable case idea. Larger than I want for a final design, it will be sufficient for a prototype.

It's 4.6" W X 6.2" H X 1.25" D. It would use 3D printed keys as well.

There's still a lot of mechanical design that will have to be done to be able to mount everything properly inside of it. There's dimensioning and tolerances of the various key holes, the display, the battery holder door, and the code module door. There would also be an on/off switch, a DB9F connector and an audio jack on the top.

With full deference to Maximilian Strauch's Apple II emulator and Jorj Bauer's Apple IIe emulator, here's my first concept for the initial prototype of the terminal board. I've already ordered some of the parts.

I had to re-arrange the pins to get the functionality I wanted. I'm multitasking some of the display data lines with the keyboard scanning to save pins. I've also fleshed out some of the design for the interfaces such as an RS232 interface to talk directly to a PC (through a USB-Serial converter), the modem signals and the interface to the code module. I'm just using logic-level serial to the code module; this should be general enough of an interface to work with all sorts of different module implementations.

The current concept for the code module is to just use a Teensy 3.2 in a 28-pin socket. I currently think that it is a general enough interface that all kinds of different implementations of different processors and technology could be used. Even if a code module is physically larger than that, it could just be a larger mezzanine board with a socket and screw holes to allow robust mounting.

The code module would implement a basic serial command interface allowing keys to be downloaded, packets to be downloaded, encoded and uploaded back to the terminal where encoded data could be output on either the RS232 interface or the modem interface. The reverse would occur to decode messages and then show them on the display.

I have some concern about the keyboard scanning approach, but I'm going to go with this simplest approach for now. I want to get something up and running to validate as many of the other ideas as possible sooner than later. In particular, I think that there is some possibility of signal radiation that would allow a snooper to monitor key inputs, so later I'll probably change the key scanning interface.

For the modem interface, there are several different possible "modes" that might be utilized to transfer data into and out of the PEU and into or out of devices such as phones. Here's a list:

1. 110/300/600 baud modem direct over cellphone audio - I've developed software modems in this
range on systems like the Teensy before. With a 180 MHz Cortex-M4F, there should be plenty
of horsepower for a simple software modem.

2. Capture the audio file on the target device, send audio file, play back audio file.

3. An App that can convert audio into binary (software modem on phone). Send the binary data file. The app then converts the binary file back to audio. Play back over speaker/headphone.

4. Use a USB device which can convert data to/from audio from/to data.
Sent data as file over email/txt.

Anyway, I have more design work to do (e.g. the power supply) as well as parts selection
before full-up prototyping.

I've started selecting parts and have updated the components list. I've also started laying out and sizing the board prototype.

Although not as small as I'd like, it's pretty small. If i figure several stages of prototypes, then I can relax dimensional standards until I have a working circuit.

The following diagram shows a typical use case for the PEU.

Messages would be entered on the PEU (an IM-ME shown for reference), a speaker/microphone cable would connect the device to a phone and messages could be sent. Obviously, as audio signals, there would need to be some kind of modem which could be implemented in software on the PEU.

With what we know from events in the past few years, we see that all states around the world continuously surveil their own citizens as well as resident and non-resident non-citizens. We know that virtually all current communication and computing devices have been compromised and turned into tracking and monitoring devices.

There is a real need for people seeking the realization of their basic human rights to be able to communicate without surveillance (or at least by making such surveillance more difficult). Individuals, non-governing political groups, monitoring NGO's, activists and journalists must be able to freely communicate without fear of surveillance. The absense of that situation stifles free speech and free expression.

There are currently no existing easy solution to this problem. This project aims to start development of a system which could lead towards greater freedom of speech, and freedom of expression and communications for all people around the world. Having widely available secure communication can be world-changing.

The issue of having relatively secure communications is an important one for many people.

Executing the development of such systems is not easy, as it often requires knowledge and experience with the kinds of attacks and compromises one might face. Often, security is compromised by trying to do too much in one system. Therefore, the idea of "do one thing well" is important to making this happen properly.

An additional issue is that, faced with sophisticated attackers, there are many compromises that may be possible. Therefore, the user must be able to trust the encoding module. The ability to develop their own encoding modules or to use a trusted source for them is important to ensuring security. The encoding modules must be projects little more in scope than arduino-scale projects and be able to be plugged into the PEU. It must be a well-defined mechanical and electrical standard which is easily complied with. The code modules should be able to utilize the most advanced algorithms available and old, known-compromised algorithms must be easily replaced.

So, the project will entail the development of the following major assemblies:

1. Terminal subsystem electronics

2. 3D printed enclosure

3. Encoding module

The initial unit will utilize a non-ordinance/non-ITAR quality coding module to demonstrate the principle and to define the design and relevant standards. Further development will be up to future users.

The challenge is to develop a general purpose communication tool which is portable, relatively secure, easy to build, easy to use and avoids the mistakes that we've found out about with smart phones and computers.

The biggest challenge will be in packaging components that are readily available into a small, durable, usable device. Doing this in a reasonably cheap unit is also important.

So, the project entails two major subsystems: 1) a portable communication terminal which can accept 2) various code modules.

The standardization of the interface between the terminal and the code module is crucial to allowing other hackers to develop their own code modules for the terminal system.

It is seen that a 3D printed packaging will be necessary to make the unit durable and portable.