So correct me if im wrong, this looks like a hardware TLS protocol
mcu ... for IOT devices, arduino, an atmel chip that sits in
between a device and tha interweb so that TLS-less devices can
connect to ssl/TLS services....
Rather cool. on a card..in a ][?
not too different than a wiznet...
hmm alongside a wiznet? https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-45176-Harde ning-Transport-Layer-Security-for-IoT_Flyer.pdf

bobbi manners are you reading this?
Speccie?
--
die thensoar


----Android NewsGroup Reader---- https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

So correct me if im wrong, this looks like a hardware TLS protocol
mcu ... for IOT devices [...] https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-45176-Harde ning-Transport-Layer-Security-for-IoT_Flyer.pdf

This chip is the opposite of a chip for IoT devices. It's a chip for data center application. Its encryption capabilities are not related to SSL/TLS.

Regards,
Oliver

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Barana wrote:

So correct me if im wrong, this looks like a hardware TLS protocol
mcu ... for IOT devices, arduino, an atmel chip that sits in
between a device and tha interweb so that TLS-less devices can
connect to ssl/TLS services....
Rather cool. on a card..in a ][?
not too different than a wiznet...
hmm alongside a wiznet? https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-45176-Harde ning-Transport-Layer-Security-for-IoT_Flyer.pdf

I'm not so sure that that is the primary purpose of this device. The description sounds more like its purpose is certificate-based
authentication.


From the PDF that you referred to:
-------------

The Atmel® Hardware-TLS (HW-TLS) software libraries for wolfSSL and OpenSSL enable hardware-based elliptic curve mutual authentication for TLS using the Atmel CryptoAuthenticationTM ATECC508A Crypto co-processor. Currently, de- signers of embedded systems and IoT devices relying solely on TLS for network/ecosystem security have few options for strongly authenticating the identity or origin of the remote device. In addition, certificates and
private keys are currently stored in software, which leaves them more vulnerable to attack. With Atmel HW-TLS support libraries, system designers using wolfSSL or OpenSSL can take advantage of Atmel Crypto hardware to
enable strong mutual authentication between communicating devices as well as for storing keys, certificates and other sensitive data in a protected
hardware device.

The wolfSSL and OpenSSL libraries allow customers using those software
packages to harden their networks on the transport layer with the ATECC508A device. Unlike other hardware solutions that only offer encryption and hash acceleration, the ATECC508A embeds a root of trust within the chip that provides a unique, verifiable identity within each device that uses it. Encryption is necessary, but it only prevents eavesdropping and cannot
verify the identity of the other party. Using the ATECC508A, you can now
verify the identity of the entity with whom you are communicating. Additionally, with the Atmel
HW-TLS libraries from wolfSSL and OpenSSL, users can significantly enhance
TLS communication security by implementing hardware-based authentication and secure key storage.

Atmel HW-TLS also makes it easy to implement strong elliptic curve authentication on the transport layer as well as the application layer.


Key Features
• Elliptic Curve Authentication enables robust identification of autonomous IoT nodes
• Secure Hardware Key Storage for TLS implementations to protect security keys from intrusion as well as physical attacks
• Cryptographic Co-Processor for rapid authentication and key agreement processing; low power sleep mode, and code space reduction for host
processors
• Flexible software and APIs to allow custom Application Layer security
needs beyond TLS
• Atmel Certified-ID platform for secure provisioning of any IoT or cloud ecosystem
• Readily available solution with downloadable software packages for
wolfSSL, OpenSSL and Atmel Studio supporting the ATECC508A device

--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Barana wrote:

So correct me if im wrong, this looks like a hardware TLS protocol
mcu ... for IOT devices, arduino, an atmel chip that sits in
between a device and tha interweb so that TLS-less devices can
connect to ssl/TLS services....

By the way, after several weeks of research, I came to the conclusion for myself that the least-complicated way to get TLS access for old Apple
computers is to use an Apache web server with its TLS proxy modules.

What you do is to send a GET request to the proxy web server which has a fully-qualified URL, ie, https://macgui.com/vault/ in the GET line.

The web server proxies this request, then returns the HTTP response back to
the client (my Apple II, or whatever) as plaintext.

Note that the proxy also takes care of a DNS lookup.

This proxy server could be local to your home network, or it could be hosted
on the public Internet.

The Apache web server can also proxy FTP requests through HTTP.


--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

[...] This proxy server could be local to your home network, or it could be hosted
on the public Internet.

...or it could run on a Raspberry Pi connected via a short patch cable
directly to your Uthernet II. Then the Raspberry Pi could also work like a wireless bridge for the Apple II. Additionally you could run other programs
on the Raspberry Pi:
- ADTPro Virtual Ethernet Drive
- Emai//er Email Gateway (http://bobbi.epizy.com/?i=1)
- ...

I created some related info: https://github.com/a2retrosystems/uthernet2/wiki/Uthernet-II-and-Raspberry-Pi

Regards,
Oliver

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Barana,

So correct me if im wrong, this looks like a hardware TLS protocol
mcu ... for IOT devices, arduino, an atmel chip that sits in
between a device and tha interweb so that TLS-less devices can
connect to ssl/TLS services....
Rather cool. on a card..in a ][?
not too different than a wiznet...
hmm alongside a wiznet? https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-45176-Harde ning-Transport-Layer-Security-for-IoT_Flyer.pdf

bobbi manners are you reading this?
Speccie?

Interesting. I am not a hardware guy, so cannot immediately help with this. If it was between an Uthernet card and the net, then we should not need to do anything with Marinetti, but if it was instead of an Uthernet card, then we would need a new Link
Layer which I could help with...

Cheers - Ewen (Speccie)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Ewen,

[...] but if it was instead of an Uthernet card, then we would need a new Link Layer which I could help with...

Network devices with hardware encryption support to be used for SSL/TLS all have this issue:

A "modern" (e.g. Linux) program using SSL does so in user space, not in the
OS kernel. But the device comes with an OS driver. Therefore those devices
have proprietary (usually very complex) interfaces to interact with the
user space program. That interaction is encapsulated in patched versions of popular SSL libraries.

So for Marinetti to make use of the encryption features of such a device,
it would need to
a) support that complex interaction. E.g. typically, the very expensive asymmetric SSL handshake isn't done by the device at all. Rather it "only"
does the symmetric stream encryption.
b) supply an API to GS/OS program allowing to declare that SSL is desired.

From my perspective, a device targeting low end IoT scenarios would be
_way_ more suited to "our" use case.

However, such a device would pose its own challenges for GS/OS. Such
devices allow to open - typically one - TCP connection to a hostname. And
that connection can optionally be a secure one (aka SSL/TLS). But that
implies that the whole TCP/IP stack is implemented on the device, not on
the "host".

So such a device can't be used _with_ Marinetti. It can only be used _instead_of_ Marinetti. Maybe one could create a Marinetti-compatible
interface for such a device allowing some/many/most Marinetti programs to
work with it instead of Marinetti.

Regards,
Oliver

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Oliver,

So such a device can't be used _with_ Marinetti. It can only be used _instead_of_ Marinetti. Maybe one could create a Marinetti-compatible interface for such a device allowing some/many/most Marinetti programs to work with it instead of Marinetti.

Thank you for the detailed explanation.

Cheers - Ewen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)