Created Date: September 21,2017

Created by: MikeN

BRX doesnt really support all the necessary security stuff to use most email servers/services. If you are able to use the email through an unsecured, unencrypted means then it does work quite well, but the actual features for using email properly to any sort of basic standards of the modern age is non existent. The only feature the Do-More (which BRX is) supports is a basic login, nothing else.

It shouldnt be very hard to store some basic security credentials in the PLC memory to use proper email. Hopefully Host will add real support for this soon.

Created Date: September 21,2017

Created by: BobO

BRX doesnt really support all the necessary authentication stuff to use most email servers/services. If you are able to use the email through an unauthenticated, unencrypted means then it does work quite well, but the actual features for using email properly to any sort of basic standards of the modern age is non existent.

It shouldnt be very hard to store some basic credentials in the PLC memory to use proper email. Hopefully Host will add real support for this soon.

We support several authentication methods, including AUTH LOGIN, AUTH PLAIN, and POP before SMTP, so I'm not sure what you mean by "but the actual features for using email properly to any sort of basic standards of the modern age is non existent ". I 've sent email through Google and Microsoft, and most major carriers have methods. It really isn't that difficult.

As for Host doing the work to "store basic credentials ", it isn't an issue of credentials or willingness on Host's part to do the work, it's an issue of encryption. The SSL encryption routines are memory hungry and processor intensive, and neither are friendly things in small PLCs.

Created Date: September 22,2017

Created by: BobO

C'mon BobO, where's the command for "brew coffee ", and "get me a muffin "?

We'll get IoT in there soon, so your automated bagels-n-Joe can happen. I mean seriously, are we savages? Of course not. ;)

The OP's question is valid, but the suggestion that it's simple and Host is just slacking is inaccurate. I'm pretty sure we can do it, but it isn't trivial to do time consuming operations over 100s or 1000s of scans when you run bare metal (no OS) as we do, when the encryption libraries aren't written to accommodate that. And that's assuming that we can find a library that fits in available resources, or at least resources we are willing to allocate to this. Since we do want to implement IoT soon, having SSL will be helpful for that too, it's just a matter of priority. Host doesn't have unlimited development resources, we have to choose our battles, and right now the focus is getting BRX modules developed.

Created Date: September 22,2017

Created by: BobO

Pretty sure BobO is really tired of me talking about this one to him. As he stated, it's just not that simple. We have a saying in the ADC Do-more group; "It's just bits. Until it's not. " Loosely translated this means that some things are dirt simple to do. Others, not so much. SSL and TLS belong in the "Not so much " bucket.

There are libraries. We can do it. We want to do it. Just takes time.

Created Date: September 26,2017

Created by: MikeN

We support several authentication methods, including AUTH LOGIN, AUTH PLAIN, and POP before SMTP, so I'm not sure what you mean by "but the actual features for using email properly to any sort of basic standards of the modern age is non existent ". I 've sent email through Google and Microsoft, and most major carriers have methods. It really isn't that difficult.

As for Host doing the work to "store basic credentials ", it isn't an issue of credentials or willingness on Host's part to do the work, it's an issue of encryption. The SSL encryption routines are memory hungry and processor intensive, and neither are friendly things in small PLCs.

I edited my post to word it to be more clear. While the BRX does support a basic login authentication, it does not support any basic security standard for the past couple of decades. Those are the features that are necessary yet unsupported. A login is not considered security by any stretch of the meaning, especially since the PLC is sending it completely open and in the clear where anyone can not only see the username but also the password used.

Some ideas for implementing security for the communications:

Add it is and just put a warning by the tick box that using the secure method will take hundreds of cycles. Possibly make the instruction yield so as not to lock up the PLC for a few hundred milliseconds and instead only increase scan time by 2-3ms each scan cycle the instruction is working.

Change parts of the FPGA layout to dedicate a small portion for accelerating a secure communications

Use one of the reserved busses for future platform expansion to go to a small, cheap security processor that will handle all the work for you so as not to tie up the main processor and scan time

Use a little Trusted Platform Module to store some of the secureity certificates and credentials so that the PLC doesnt have to generate everything each time and can save a bit of scan time.

Maybe only add the secure method to a communication add-in module and use that module to have the necessary acceleration methods so that the main CPU and scan is not affected. (This is how some Allen Bradley stuff implemented secure communication)

If you are using an ARM processor instead of an FPGA as your main CPU in the BRX then just use the security block of the AMD CPU, they have had them built in for years and years now.