Barely Encrypted? [Solved - good enough]

Go To Last Post
48 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greetings -

 

I'm designing a really light-weight wireless network and want to include a bit of encryption. Just a bit more than simply obscuring. All of the data will be ASCII (numbers, mostly). So each byte will be between 0x01 and 0x7F (inclusive). One possibility is to simply add a number (that might change from message to message in a known pattern) between 0 and 0x7F to each byte (same number applied to all bytes in the message).. That is sort of the minimal obscuration. I guess what I am looking for is just one step above that. 

 

Any suggestions?

 

Thanks

Jim

This topic has a solution.

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Fri. Jun 3, 2016 - 04:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is this one way, or two way links ?

Most cracks can work-back from knowing the information being sent, so how variable that is, determines how well simple scramble schemes could work.

If you want to protect against unlicensed product creep type issues, then some serial number approach is going to be needed.

 

You can use a LFSR to give a longer timebase to the scramble scheme used, and they are compact to code. You are free to choose any length (eg not 32 or something common)

and the apply it in any way...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

These are two way links. The purpose is less to keep the contents secret than to keep them from being spoofed. I want to make it just enough so that someone who has somehow obtained code but has only used it to clone a network member cannot easily inject false data into the system. I know that anyone who makes the effort will be able to crack anything I can do. I just want to make it a bit challenging for the local hacking kiddies bent on vandalism.

 

The system is already "encrypted" in the sense that frequency hopping spread spectrum provides - any intruder needs to figure out the hop table before they can do anything else. So that is the first level of protection. And, it won't be in flash.  But, if someone has hardware or cracked code, that part won't be hard to figure out. Clearly, anyone who has the resources to deal with that won't have much difficulty with a rudimentary message obscuring algo, but I figure that is better than nothing, so long as the system cost is low.

 

Some of the system components will be near public roads as a flood warning system. I simply want to reduce the chances of the system providing false information as a result of being attacked. The most likely of these attacks is through the wireless network rather than the internet gateway. The internet side has similar problems but that  side is also perceived to be far more dangerous.

 

Jim

 

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Fri. Jun 3, 2016 - 04:57 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

... to keep them from being spoofed. I want to make it just enough so that someone who has somehow obtained code but has only used it to clone a network member cannot easily inject false data into the system.

 

It sounds like you want the network node to 'sign' the data it sends.

 

For a lightweight signature you can use a modified CRC.  The modification is to insert a Pre and/or Post string before and after the data string in calculating the CRC.  Only the data string and CRC would be transmitted.  Both the sender and receiver would know the Pre and Post strings.  Checking the CRC would verify that the sender was authentic and that the data was received without any errors.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would try to EOR with a sekvens of something like 16 different numbers. (perhaps first byte used as a seed).

That will look like a mess quite fast.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Google's top hit for "simple encryption" is this:

 

https://en.wikipedia.org/wiki/Ti...

 

The reference code looks "simpleish". Also notice the list of "External Links". The one to AVR Asm could have been very useful if it wasn't a 404 error! As that is dead if you then just google "tea avr asm" you hit links such as:

 

https://www.avrfreaks.net/forum/t...

 

possibly the most useful post in that thread leads to:

 

http://www.efton.sk/crypt/avr/xt...

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did not get a 404 on the tea-asm-avr site. Attached the source in case somebody else have problems.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chuck99 wrote:

ka7ehk wrote:

... to keep them from being spoofed. I want to make it just enough so that someone who has somehow obtained code but has only used it to clone a network member cannot easily inject false data into the system.

 

It sounds like you want the network node to 'sign' the data it sends.

 

For a lightweight signature you can use a modified CRC.  The modification is to insert a Pre and/or Post string before and after the data string in calculating the CRC.  Only the data string and CRC would be transmitted.  Both the sender and receiver would know the Pre and Post strings.  Checking the CRC would verify that the sender was authentic and that the data was received without any errors.

 

 

 

Now there's an interesting idea. I've been thinking of encryption for the same purpose, but this might just provide protection I'm looking for. 

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, Cliff! :-)

 

However, the real stuff is at https://www.das-labor.org/wiki/A...

 

Jan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the perceptive suggestions, everyone! I Like chuck99's idea! That would solve the authentication issue with no additional payload. Nice!

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Fri. Jun 3, 2016 - 03:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a working PC1 Pukall Encryption Example if you want me to send it you?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, Fianawarrior - I'll pass on that since I've realized that I am really not after encryption but after authentication. 

 

Appreciate your offer,

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess it's a bit "heavy" but I've done the authentication (aka signing) thing using SHA256 in the past. Say you want to verify the phrase:

 

"now is the time for all good men to come to the aid of the party"

 

You can pass this through a has function like MD5 or SHA256 and get something like:

$ echo "now is the time for all good men to come to the aid of the party" | md5sum
ff1cae4977e6a07d0e59d38287eb1fe1  -

but what you, and the other end, keep secret is an additional pass phrase that won't be transmitted and you prepend this to the data. Something like:

 

"To be or not to be, that is the question".

 

So locally you pass both in turn into the hash function:

$ echo "To be or not to be, that is the questionnow is the time for all good men to come to the aid of the party" | md5sum
1b76fd05631096b5b9fcd3814f9c709e  -

Now you simply send:

 

"now is the time for all good men to come to the aid of the party", 1b76fd05631096b5b9fcd3814f9c709e

 

to the other party. He then starts by passing the hidden phrase "To be or not to be, that is the question" through his own hash function. Then he puts the transmitted payload ("now is the time for all good men to come to the aid of the party") through the function too. Finally it compares the result of the hash to see if it comes up with 1b76fd05631096b5b9fcd3814f9c709e (you probably only need a few bytes of that in fact). If it generates the hash you know this was sent by someone who knows the hidden "To be or not to be, that is the question" secret. So they must have the right to send you data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In this case, does lightweight wireless imply that keys can be hand-delivered?

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Keys will be supplied when each unit is provisioned. There will be a "default key" that code will use in the absence of a provision-supplied key and that will identify a unit as being "alien". At least that is my idea.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Thanks for the perceptive suggestions, everyone! I Like chuck99's idea! That would solve the authentication issue with no additional payload. Nice!

 

There is one hole in the modified CRC approach. 

A false node could record a data packet sent by a true node and re-transmit it later.

The receiver would accept this old packet since it would pass the CRC test, corrupting the data log with old data.

 

A way to prevent this is to have each node include a packet number that is incremented with each transmission.

The receiver would need to remember the last packet number for each node and throw away any packet whose number was less or equal to the last.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for that.

 

Jim

 

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems like you want authentication instead of encryption. Since you are able to share a key between both parties in advance, you can just send a plain text message along with a message authentication code (MAC). The party that receives the message then verifies that the MAC is correct by recreating it and comparing it to the one received. This guarantees that the message was created by an authorized device/user. In order to prevent a replay attack (which is when someone sniffs the message and resends it later on) you can add a nonce to each message. Basically this is a number that gets incremented every time you send a mesaage. So if you send nonce + message + MAC(nonce + message), you know the message is authentic and can't be replayed since the nonce won't be valid then.

If it must be encrypted also, you can use authenticated encryption like aes-gcm. There is also a very light weight AVR library called avrnacl that does authenticated encryption using elyptic curves and is very easy to use.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How much data will be sent compared to how much storage is available and how often you have physical access to the end nodes? You could store a one-time pad on each unit and xor the outgoing messages for complete security.

 

Never never never reusing the pad of course.  Well, hardly ever ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MuTeD wrote:
It seems like you want authentication instead of encryption.
Atmel recently added one AVR, XMEGA A3BU, to CryptoAuthLib; there's a porting guide within the document for that library.

There's an Atmel crypto authenticator IC on the new Arduino WiFi shield; an assumption is there's Arduino source code for that crypto authenticator.


Home > Products > Security ICs > Atmel CryptoAuthentication > SHA-based Devices

CryptoAuthLib

http://www.atmel.com/tools/CryptoAuthLib.aspx

CryptoAuthLib is a software support library for the Atmel ATSHA204A, ATECC108A and ATECC508A CryptoAuthentication devices written in C.

...

CryptoAuthLib Firmware Library 20160108
(12MB, updated January 2016)

(in "README.md" is "- XMega A3Bu HAL implementation")

CryptoAuthLib has ports to Linux and Windows; therefore, a custom network interface can be authenticated to a Linux or Windows application.

 

https://www.arduino.cc/en/Main/ArduinoWiFiShield101

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simplest way if to use a free open source AES implementation. AES is the best speed and security combo on embedded platforms. Requires less than 2K flash and about 500 bytes SRAM for AES-128.

 

http://avrcryptolib.das-labor.or...

 

Download tree snapshot here (may take a few seconds to start downloading):

 

https://git.cryptolib.org/?p=avr...

Last Edited: Sat. Jun 4, 2016 - 04:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hugoboss wrote:

Simplest way if to use a free open source AES implementation.

I don't think plain AES helps him a lot. While it is a great encryption cipher, it is used to encrypt data,
not authenticate it. This is a big difference. Encryption e.g. i store something on my hard drive that only I should be able to read. Authentication e.g I send a message and prove that it comes from me. These are two completely different things in cryptography. Plain AES:
1) offers no authentication or integrity
2) might be vulnerable to replay attacks (depending on the mode and implementation)
3) without a block cipher mode of operation, you can't encrypt more than 1 block of 128bits, you could use ECB mode. While it's pretty crappy (see here: https://en.m.wikipedia.org/wiki/Block_cipher_mode_of_operation) it might be good enough for him.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My earlier comment seems to have been lost. 

 

The largest packet will probably be 16 bytes. Maybe 32 absolute tops. Actual data payload will usually be 4-6 bytes. There will be a network source ID and network destination ID (2 bytes, each) and a message number (maybe 1 byte) in there also. CRC16 tacked on the end. Something that adds a bunch more bytes does not meet my "lightweight" goal. Neither does 500 byte SRAM in a device with only 2K  of SRAM. Anything that adds lots of bytes also impacts the power budget due to increased transmitter on-time (not only for the source and destination but for every device the message passes through).

 

I've finally realized that encryption (in most cases) is not what I want, but some messages might (where the host sends control commands to other network members). Even in this case, the actual payload is only a few bytes.

 

Computational speed is not much of an issue as the transmit rate will idle at maybe once an hour and might bump up to 4X per hour. Data transmit rate is quite low, though that may not be relevant to the discussion.

 

Thanks for the input, all...

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Sat. Jun 4, 2016 - 08:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not aware of an authentication algorithm that doesn't add a number of bytes and can't be replayed. I also don't know how that would work, would be interesting to see!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MuTeD wrote:
I'm not aware of an authentication algorithm that doesn't add a number of bytes and can't be replayed. I also don't know how that would work, would be interesting to see!

 

Well actually, it's pretty simple:

 

1. The message includes a message number that changes on each message.

2. You add on a CRC calculated from the message contents including the message number and some key known to both the sender and receiver.

 

When the message comes, the receiver checks the crc against the message contents and key. If it isn't right, the message isn't from the sender. Next, the receiver looks at the message number. If it's less than or equal to one already received, it's a repeated message, possibly sent by a stranger.

 

Without knowing the secret key that's not part of the message, a villain can't calculate the correct CRC for a message with a new message number.

 

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Torby wrote:
1. The message includes a message number that changes on each message. 2. You add on a CRC calculated from the message contents including the message number and some key known to both the sender and receiver.

 

Sorry, I misread, I thought he didn't want to add CRC16 (or anything else) to each message.

 

That said, CRC (and the described protocol) is extremely weak for authentication. CRC is meant for error detecting code and not as a strong one way function. In fact, it is a very weak one way function and can easily be reversed.

 

Adding a key to the message to add authentication is basically trying to make your own Message Authentication Code (MAC, not to be confused with MAC address, they have nothing in common). Making a secure MAC yourself is not something I'd attempt, there is a reason there are only a few that haven't been broken. I'm not sure I understand why you would attempt to make your own MAC rather then just using an existing, proven secure MAC. I'm pretty sure you could find an easy to use library for this.

 

ka7ehk wrote:
There will be a network source ID and network destination ID (2 bytes, each) and a message number (maybe 1 byte) in there also. CRC16 tacked on the end. Something that adds a bunch more bytes does not meet my "lightweight" goal.

If you'd use a MAC you don't need the CRC16 anymore as a mac does both data integrity and authentication. The downside is that you add quite a few more bytes. For example, HMAC-SHA1 adds 20 bytes. The other downside is that it is more computationally expensive. I guess that's the cost of having something secure :). You could of course just not care about this and assume nobody is going to try and reverse it in which case you can go for "security through obscurity".

Last Edited: Sun. Jun 5, 2016 - 03:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The wireless devices do not appear to have a manufacturer-defined MAC. Thus, it appears to me that any MAC I try to implement in firmware can be duplicated. Thus, my search for some MAC-replacement that is "sufficient".

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

It seems you are referring to a Media Access Control (MAC) address and not a Message Authentication Code (also called MAC). These two have nothing in common. Sorry If this wasn't clear from my last post.. I was referring to the latter.

Last Edited: Sun. Jun 5, 2016 - 03:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

More than sufficient is an ATECC508A (SOIC or UDFN; keys, MAC, hash, random number generator; about 1USD).

http://www.atmel.com/tools/CryptoAuthLib.aspx?tab=documents

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

More than sufficient is an ATECC508A (SOIC or UDFN; keys, MAC, hash, random number generator; about 1USD).

http://www.atmel.com/tools/CryptoAuthLib.aspx?tab=documents

 

Why is this device only available under NDA?

Building my dreams!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its complete datasheet is NDA.

Its available; https://octopart.com/search?q=ATECC508A

Its interface software is in CryptoAuthLib.

 

Edit: typo

"Dare to be naïve." - Buckminster Fuller

Last Edited: Sun. Jun 5, 2016 - 05:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
More than sufficient is an ATECC508A (SOIC or UDFN; keys, MAC, hash, random number generator; about 1USD).

Atmel's page shows the SHA devices for authentication as well http://www.atmel.com/products/se...

http://www.atmel.com/devices/ATS...

Also about a buck qty. 1 and well stocked at distis.

 

===================

I guess it depends on the importance to Jim's app.  If important (e.g. auto keyfob that unlocks) then a buck may well be worth it, and the device that implements a proven protocol.

 

If the buck and space is important, then perhaps one can implement something simpler "in the manner of" SHA or others just to foil lookey-loos.

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
... (e.g. auto keyfob that unlocks) ...

RF Digital

Product Categories

KEYFOB Remotes

http://www.rfdigital.com/product-category/keyfob-remotes/index.html

The transceiver in each keyfob can be married to numerous other transceivers of that kind (RFDP8) and each has a 32b serial number.

 

Some transceivers have a crypto engine :

Home > Products > Wireless Connectivity > 802.15.4 > Smart Energy > Wireless Communications > Transceivers

AT86RF212B

http://www.atmel.com/devices/AT86RF212B.aspx?tab=parameters

...

Crypto Engine:

AES

...

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Microchip Technology Inc

Microchip Releases Industry’s First End-to-End Security Solution for IoT Devices Connected to Amazon Web Services’ Cloud

https://www.microchip.com/en/pressreleasepage/microchip-releases-industry-first-security-solution-amazon-web-services-cloud

Microchip’s Pre-Configured ECC508 is the Simplest Way to Create Secure Mutually Authenticated IoT Connections with AWS


CHANDLER, Ariz., Aug. 11, 2016

...

Microchip and AWS collaborated to develop this integrated solution to help IoT devices quickly and easily comply with AWS’s mutual authentication IoT security model.

...

In volume production, the generation and secure handling of these unique keys can be a daunting challenge in the chain of manufacturing especially where third parties with different trust and compliance levels are involved.

...

Customers simply solder the device on the board and connect it over I2C to the host microcontroller (MCU) which runs an AWS Software Development Kit (SDK) leveraging the ECC508 device for AWS IoT.

Once this is complete, there is no need to load unique keys and certificates required for authentication during the manufacturing of the device as the AWS-ECC508 is pre-configured to be recognized by AWS without any intervention.

All the information is contained in a small (3x2 mm), easy to deploy crypto companion device.

...

A typical IoT device consists of a small [8-bit] microcontroller, and is battery powered. 

...

The ECC508 device has a low-power processor-agnostic cryptographic acceleration for compatibility with the widest range of resource constrained IoT devices.

...

The encryption key is either generated when the tested PCB is entered into your inventory, before shipping to the customer, or during provisioning at the operator.

The certificate for AWS is already inside an ATECC508A-(3 letters for package)AW


EDN

Secure chip works with Amazon Web Services

by

August 14, 2016

http://www.edn.com/electronics-products/other/4442548/Secure-chip-works-with-Amazon-Web-Services

...

The kit (AWS Zero Touch Secure Provisioning Kit) ... in-situ provisioning by the supplied Signer Module.

...

 

Edit : EDN

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. Aug 16, 2016 - 06:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Might be a bit late to this thread, but I once implemented a sixteen-bit LFSR in a lil' AVR.

 

It was supposed to generate pseudo-random ASCII for a Morse code trainer ("Code Groups"), but it also generated a "start key" which it told you, and by using that exact same start key it would then replay exactly the same pseudo-random ASCII so you could check your work.  Never really finished it, but the random code group stuff worked just fine.

 

IYI on LFSRs:

Imagine a fixed array of 65,536 bytes randomly generated once.  The array being fixed, in theory if you know the entry point and the whole array then you can predict the next value.  Alternately, if you hear a certain unique sequence and you know where that sequence is in the array, and know the whole array, again then you can accurately predict the next one.  I further obfuscated it by mapping the bytes to an alphabet (which was programmable, in both size and members - part of the idea was to train on certain characters, too) which threw away a lot of high-bit information, making the "unique sequence" a lot harder to find.  Still can be done, of course, without too much trouble, but for a Morse Code trainer it's not worth your time trying to memorize it (especially when, if they want to, those administering the exam need simply flip a couple of letters in the alphabet (abcdef... becomes acbdef...) and the sequence goes all haywire.  But with the same alphabet and the same starting code, you will always get the same thing - required for proving you got it right.  I thought it was cute.

End IYI on LFSRs.

 

If anyone's interested, let me know.

 

S.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Embedded

Single-chip end-to-end security for IoT devices connected to the Amazon cloud

by

August 18, 2016

http://www.embedded.com/electronics-blogs/max-unleashed-and-unfettered/4442574/Single-chip-end-to-end-security-for-IoT-devices-connected-to-Amazon-cloud

...

This includes an industry-first called the Just in Time Registration (JITR) certificate registration process.

...

Using a physically unclonable function (PUF), the ECC508A features internal generation of unique unreadable private crypto keys, which streamlines production by removing the need for HSMs (Hardware Security Modules), secure rooms, and factory audits along with the need to trust custodians in the manufacturing chain.

Pre-configuration with AWS IoT server requirements eliminates complicated setup and facilitates the hassle-free automatic registration and onboarding of IoT Devices.

...


Atmel Launches New Security Platform Enabling Companies of All Sizes To Develop Secure Internet of Things Applications

http://www.atmel.com/about/news/release.aspx?reference=tcm:26-73463

New Atmel Certified-ID Platform Eliminates Barriers of Entry to Secure IoT Ecosystem; Enables Hassle-free Secure Certificate Generation and Security Tool Kits for Smaller Businesses

San Jose, Calif., November 9, 2015 – ...

...

Edit : HSM

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Sat. Aug 20, 2016 - 04:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

InfoWorld

Murder in the Amazon cloud

by

Jun 23, 2014

http://www.infoworld.com/article/2608076/data-center/murder-in-the-amazon-cloud.html

The demise of Code Spaces at the hands of an attacker shows that, in the cloud, off-site backups and separation of services could be key to survival

...

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I don't like this encryption thing.  You must be a very dull man.  wink

 

 

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"BRIDGE CONSTRUCTION

AIM FOR WORKERS"

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hugoboss wrote:
Simplest way if to use a free open source AES implementation.
Though not quite open source there's a new AVR app note on AES including ECB for mega328PB.

The app note states Atmel START but it's not yet in START.

http://www.atmel.com/Images/Atmel-42784-Software-Library-for-AES-128-Encryption-and-Decryption-on-megaAVR_ApplicationNote_AVR284.pdf (2016-09)

http://start.atmel.com/

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ATECC508A is in Atmel START for SAM D21, SAM L21, and SAM W25.

Might be worth an evaluation of a port to a megaAVR.

Atmel START

Atmel START

http://start.atmel.com/

BROWSE EXAMPLES

Category pull-down menu

Cryptography

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The easy way that can be coded by anyone are the one time pads where every message is XORed with a variable length sequence of values. The problem of course is to devise an algorithm to update the pads every now and then. It might defeat the occasional snooper but I wouldn't trust it for anything important.

The major weakness is that this kind of sensor messages usually have a constant format and a very limited alphabet (0-9 plus maybe a separator) and being a simple xor it's quite fast to brute force.

 

--
just another pipe hacker

Last Edited: Sun. Apr 30, 2017 - 11:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am less concerned about a snooper reading sensor data because that data is/are public. What I AM concerned about is spoofing of sensor data (eg, false data) and spoofing of control commands from the host.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In fact I think it will depend of the capabilities of the sensor.

I don't know if any AVR chips are capable of https but if they do that would be a good solution.

May I ask how are you planning to connect the sensors to the wifi network?

 

--
just another pipe hacker

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The sensor network will be NOT connected to the internet (LoRa). All access will be through a gateway app in the gateway. All ip access terminates in that app and control of the network will not be accessible through command-line, telenet, or anything else. The gateway app has total control of the network and that control is not available externally; you have to be physically AT the gateway to do it. Gateway will probably be of the RaspberryPi-class of device. The sensor network is invisible to the gateway OS.

 

Think of it like this. Suppose that I have an interface board that connects to the gateway via I2C or SPI. That interface board has an RS232 port. Without a special driver, that RS232 port will be unknown to the OS and will never appear as a COM port. Ditto the sensor network. That "driver" is the gateway app, in this case, and does not expose the sensor network to the OS.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Mon. May 1, 2017 - 12:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, I was not thinking internet, I was thinking https with your gateway. A Pi is totally capable of running an Apache server with https, the question is if the sensors can handle it.

You wont need a special app to control the sensors all could be done with web pages. If https could be used, an unique id for each sensor would be trivial to implement. And the control from the server could not be faked because the sensors would get the commands inside the https connection.

 

I've been tinkering with an ESP8266 with a temp/humid/pressure + luminosity reporting to an Apache on a PI but https is still not available (and I don't know if it will ever be) for this modules.

--
just another pipe hacker

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Forget it. That is the way I am going to do it.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ups, sorry, no offense.

--
just another pipe hacker