Start a new topic
Not Taken

Security and unique identification.

         Lack of user coding ability is not the same as Hardware lacks the ability.   
                   Bashing for such is just simply not in the correct manner.                  

Hello.

One of the main problem with the Nextion displays is the absolute lack of security features. I suggest to the iTead team to add some minimal features

  1. bitwise operators, especially XOR, AND, and OR operators. This is only to allow a minimal encryption in communicatios (not with few effort with processing in the nextion side).
  2. unique ID, serial number, etc. should not be stored in the external eeprom.

As I said, security does not exist. And security is quite important in the modern world especially for bussiness. We are concious that 100% of security doesn't exist, but Nextion is in the opposite side with 0% of security, offering no support for even the most minimal security implementations.

Operators for encryption are important. This won't prevent the transparency in communications but help. If support were native, meaning ALL the communication encrypted (even with a basic level, xor, etc.), that would be the best. Unique identification of displays not accessible externally is a must.

Now it's completely accesible at hardware level, and can be changed so easy as replacing the eeproms or reprograming them externally. So your "unique" display is not unique anymore. I say all of this because we could clone the products without much effort, replacing displays easily and avoiding any security measure placed in our product. Not a good deal, resulting in Nextion displays are completely unsuitable for comercial products unless you don't care about being cloned. Please take into consideration this.

sorry, with all respect but I am not sure if you know about what you speak ...


    - Nexttion HMI Displays are based on STM32 / GD32 Cortex Core MCU's ...

    - Firmware is flashed with code-protection fuse set ...

    - compiled TFT files are encrypted native code files ...


    - Nextion Displays are local used, connected via RS232 interface, where is the need to encrypt the serial local datastream to your remote mcu?


    - every flashed TFT can make any display unique, just choose an ID. Your TFT is not saved in any eeprom ...

    - a TFT is native STM code, flashed directly into your STM ...


You surely can replace your STM, or even reprogram it, but then you have nolonger a Nextion HMI Display, you just have a dumb black LCD panel ... and we won't give you the bootloader firmware to reactivate your Nextion again ... :-)


About cloning, to clone a STM is the same hard or easy as cloning a PIC, AVR, LPC or any other MCU out ...

That has nothing to do with Nextion displays ...





And what kind of security do you use for a monitor?

As far as I know my desktop monitors are also not encrypted.

 - actually they are not, there is no uncertainty about it.


1) Sorry, Encryption can indeed be programmed with out XOR AND OR

    a bit more processing indeed, but hardly impossible.

2) Every Nextion has unique serial number

    Basic models have no external EEPROM but have Unique Serial Number.

    but is this now stored in invisible non-existent external EEPROM?


Nextion is not lacking 100% security with 0% security

 - but it seems your understanding of security is indeed less than 100%

Replacement of EEPROM does not change Unique Serial Number

 - 1K EEPROM is 100% user data storage.


Before bashing Nextion for your lack of understanding

  maybe investigate before you spout.

You will look less like an ass because of your ass-u-mptions

Let me to rephrase the question, after contacting the hardware guys:

Background
We changed the external eeproms/flash (250128 winbond) of several displays (NX4832T035_11) and the serial was following the chips, simple like that. I repeat, we removed the chips, swaped and soldered again and got the same information (than the "connect" command will return), in both cases even when the boards were different. So the serial is stored in that ic.

Question: instead storing the serial info, etc. in the same eeprom than the display TFT code, could you store it in the mcu cortex itself? Separating this info allow to do something about security (not 100% safe since you always can move all the ics from one board to another), but much more than now.

We talk about this could minimize the issue; minimize, not removal. It's important. From a bussiness point of view, it is a major issue.

I hope the main issue now it's clearer (forget about the encryption, that's for another day).

Cheers.


Ps: It's not a competition to see who knows more or has a bigger ego. Gerry Kropf could be confused about how I exposed the question, so I rephrase it. Patrick Martin has no manners simply.

I expect respect because first I deserve respect, and second I haven't been irrespectful with anyone. Some comments are out of tone, only intending to be offensive for free. You decide how the world will see you.

It's not kindergarden


Respect and Manners

  - The first thing you ever posted is to blame Nextion

  - made some accusations without basis

  - calling a flash an eeprom is only minor

  - say encryption can not be programmed and 0% security

     - well, your design is flawed - security can be had.


Blaming Nextion for a lack of understanding or skill is

   perhaps in the wrong manner, and I responded indeed.

Not like I want other readers thinking wrong statements is fact,


So since it's not kindergarden, I figure turnaround is fair play.


Unique Serial Number is Itead application, not user application.

During mass TFT upload on commercial end

   the S/N may indeed be useful for tracking and progress.

But therein lays the end of Nextion's Unique Serial Number


First design flaw is to think this Serial Number has user use

Second to base ones user design on this Serial Number

Third flaw might be to void your warranty but only close to

Fourth expecting to store sensitive data in a display.



Nextion is an HMI device Human Machine Interfacing


Press/Release Event of what component sent to MCU

MCU to display status/progress to user on HMI device


As an HMI device, there is no need for "encryption"

  - else the HMI is unusable to the end user

Do we now find a way to encrypt the BRB Button?

   or look for ways to encrypt a dial?  an LED?


Now even though I can put AES128 straight in Nextion Logic

 - warping the use of a device only because you can

   does not make it in the right manner at all.

 - this is just wrong, in the wrong manner


The TFT file is the User's HMI design, meant to run at runtime

 - again there is zero need to place sensitive data in the HMI

 - when it is designed as a template for data/text

   the MCU will send data and text as required

 - and again, the user of the HMI needs to be able to read

   the provided choices and status/alerts - or such is useless


So what do we have left ... an RTC and an EEPROM

 - I'll spare making fun of the encrypted RTC

 - so that leaves the EEPROM

 - the data stored in EEPROM does not have to be sensitive

    - this is user design, certainly not a security conscious design

 - and EEPROM data can indeed be encrypted when at REST.


So are we now worried about Serial-MCU communications

 - As stated, encryption can indeed be programmed if desired

 - but really not needed in a touch panel, wrong manner.


MCU side encryption is user domain

 - it is the user that chooses the MCU, the compiler, language

 - and indeed encryption can be had


Assumptions that security is unachievable and blame Nextion 

 - certainly in the wrong manner to come out of the gate swinging.

 - distort an HMI device to become an MCU, again a design flaw


A proper secured design will not put sensitive data on a display

A proper secured design will handle security MCU side

 - you choose that MCU,

 - you choose how to design for your security requirements

But instead blame Nextion when understanding or skill is missing.


As a Feature Request

 - we won't deplete firmware space and infringe on user HMI space

   for the needs of a few and useless for the needs of the masses.

 - and also not when such shouldn't be on the HMI in the first place.


Nextion is an HMI device, not a user secondary MCU

 - even if I can make it do some amazing things.  Wrong manner.



1 person likes this
It's not so far-fetched

Imagine for a moment that you design a product for your company, with your logo on the screen and with the appearance of your company ...

Now goes a bad person and spies transparent communications from the MCU to the nextion and gets the names of the controls and others ..
With this information you can program a different visual interface with your company logo and a totally different appearance without the author's permission.

The nextion are still young .. think that they are unbeatable and refuse to attend the improvements that the end users who are the ones who are going to decide for a product or another is not a good company policy.

Encryptation communications solve and protect your company..

Nextion displays is oriented for professionals?? or is only use for arduino generation?

Greetings.

and at which point will an encrypted serial data-transfer protect the design (including your logo)?

to copy a design, you only need to see it ...


Yes, protect entire interface of spy data and do not make cloning viable.

 

again, encrypting your serial data-stream wont protect your design in any case ...


to copy a design, you even don't need to know the internal names of anything used ...


so, where is the need of encryption in terms of make your HMI more save ...


in worst case, you copy the winbond, for use the copy again in a Nextion display?


Winbond flash without Nextion STM part makes no sense ...

It's not so far-fetched

I'm listening ... 


Imagine for a moment that you design a product for your company, with your logo on the screen and with the appearance of your company ...

Been done, keep going ...


Now goes a bad person and spies transparent communications from the MCU to the nextion and gets the names of the controls and others ..

Now you're not listening

As stated can indeed be secured, your design is flawed

Do you think you can really crack AES128 anytime soon?


With this information you can program a different visual interface with your company logo and a totally different appearance without the author's permission.

No intelligent information garnered, just encrypted garble as told

But your logo is indeed now on new product - visual is necessary


The nextion are still young .. think that they are unbeatable and refuse to attend the improvements that the end users who are the ones who are going to decide for a product or another is not a good company policy.


Encryptation communications solve and protect your company..

Encryption can indeed help, but flawed security designs with always undermine


Nextion displays is oriented for professionals?? or is only use for arduino generation?

So you are now back to bashing, hmmmm?


Greetings.


Yes, protect entire interface of spy data and do not make cloning viable.

Cloning is already viable.  So protect visual is not doable.

Hence your suggestion is somewhat flawed.


But as I already stated above

 - security with Nextion can indeed be had - not in the manner you speak of


Everything is clonable but putting obstacles improves the vulnerability. Mathematical operators its a good idea. It is a shame that the nextion are only a led. Could be much more :-(
it is much more, but nevertheless it is still a HMI display ... and neither an Arduino nor any other MCU replacement ...

just to clarify

by default, Nextion displays offer a HMI concept by design. Even a small STM is used for underlaying work, even a standard gLCD panel is part of, the Nextion neither offer all STM available things to outside nor is it a standalone Arduino replacement nor is it a replacement for any simple gLCD out. It is what it is, a HMI concept. A Human Machine Interface.

It is out of scope of any HMI concept, to take over heavy duty calculation parts. It is also out of scope of any HMI display to offer all available graphic primitives of a simple gLCD ...

In theory, many things besides HMI can be done.

- you can implement whole arcade style games in your Nextion
- you even can calculate Prime numbers on your Nextion
- you even can process a serial encrypted SQL query if you like

But again, the Nextion HMI was NEVER designed to do so, so don't expect so. As a HMI component, the Nextion should be used for the Interfacing part, and the machining part should really stay on the machine aka MCU ..

Encryption is good per se. But it should stay where it really makes sense ...


    - on the interface side, I don't see this

    - on the communication side, just use a serial to WIFI Lantronix Matchport or similar, and you have all security you like ...


If somebody has hardware access, your best encryption won't help aginst copy ...


Where I live, it cost me around 20US$ to physically open a PIC, AVR, STM, ... and read out the die directly bit for bit with an microscope ... and get the final working hex file ready to flash ...


:-)

   

Perhaps Security is one of the more advanced concepts to be mentioned.

 - discussion of security could even have been an interesting topic to debate.


Bashing Nextion is not 

 - yet when people run out of supporting arguments,

   they unfortunately they resolve to bashing Nextion.

 - worse indeed is to lead with the bashing.


Facts:

 - The majority of Nextion volume is indeed commercial, not hobby

 - Nextion is an HMI device, not an MCU, and not a primary display.

 - Human Machine Interfacing (HMI) is not a hobby practise/concept

   but indeed industrial/commercial in nature.

 - Nextion is two wire TTL Serial, ASCII text based instructions


As such Nextion can be used with 10,000+ MCU types

 - any with at least one or more hardware UART module

   or capable of bit banging two digital pins (not 36 pins)

 - using any of 130+ programming languages, users choice.


Arduino is certainly not the primary MCU used

 - there is nothing wrong in also selling to the hobbyists

 - there is nothing wrong in providing a public forum

 - absolutely such a small public forum will have hobby projects

   posted and coding questions presented

    ... as if anyone expects full commercial product designs and code

    to be posted to a public forum from commercial endeavour ??


I think when the conversation is about someone not making a design

the same or similar, I highly doubt full code and HMI will be posted.

 - any other contributions made to the community? examples, tools?

 - go with what one sees, there's no other posts to support such theory.


Copy costs less than teenagers weekly allowance.


But for security, there must be purposeful programming

 - XOR, AND, NOT, OR a must to achieve?

No, these can indeed be built if missing and used.

If security needed and one needs a missing NOT function

 - build it, use it and done.

 - such a commercial project does not miss out on security only

   because a function is not pre-built


To identify a Winbond Flash IC, but not identify the onboard MCU IC

  - so an STM32F030C8T6 with 8K SRAM and 64K Flash

  - but a promised 3584 SRAM bytes dedicated to the User HMI Design


  - so hey, when everyone is suppose to be such great MCU programmers

    where does the requested fit without breaking existing user HMI designs


And without that conversation, is there much point to discuss

    perhaps, more understanding is required and less Nextion bashing


Itead has implemented many user requests made by the users

  - making such loose statements like

    " still young .. think that they are unbeatable and refuse to attend the improvements ..."

  - Sorry, this is indeed in the wrong manner.

  - where is the sense to finally squeeze native AES128 or RSA-2048 public key

    into an 8K STM and then have no resources to load and run the user HMI design ??


Big talk about securing the Nextion device from all evils (can not be done)

    and then state (even with a basic level, xor, etc)

XOR will not provide for security, such is not an encryption

    - so a half-baked implementation is worse than none

    - reread to where if really needed, one builds and uses it and doesn't wait

      so XOR is not "needed", especially to clog the user HMI's that have no need.

    - those that needed it, already have it done.

But I will argue that security requires a solid design implementation, not flawed.

    going half-baked gives a false sense of security - of the worst kind.

Again, those that needed it, already did it

    is their code available for this?  No.  Is yours?  Right. 

    - their code, just as yours is, it's commercial in nature - certainly not for free.

 But even having their code with less than "needed" understandings ...

    leads to improper implementations ...

    - only a feeling of secure - but NOT secure

(Nextion has such and such security, but I never programmed against X threat)


So when one understands the threats they are trying to prevent

   - they don't put sensitive data in harms way

   - they implement their designs to address the threats

   - they already coded it, not needing another native command to do so.


So here is a partial list of Features Requested by users that are now implemented.


 

Editor enhancements requested by users
  Show the x,y position when designing
  Import GIF picture resources (non-animating)
  Reorder Picture ID
  Click to get larger view of image
  Working panes resizable
  Select Multiple components
  Keyboard Shortcuts for Cut/Copy/Paste
  HMI name in Nextion Editor Title Bar
  Component Layering with Bring Top and Bring Bottom
  Change Drawing order of Objects
  “Do you want to save Changes”
  Undo and Redo
  Check for new Versions from Menu
  View per version change list before update
  Align Options from Tool Bar
  Run more than on instance of Nextion Editor
  Horizontal/Vertical upgraded to 0°, 90°, 180° and 270°
  Import a page from another project
  Escape support for newline  (supported with \r)
  Click compile error to jump to error in code
  Font enhancements requested by users
  Cyrillic Text Support (supported with iso-8859-05)
  Korean Text Support (supported with KS_C_5601-1987)
  GB3212 Text Support (supported with GB2312)

Hardware enhancements requested by users
  Bezel files for Nextion Models
  Capacitive Touch with Enclosure
  Nextion IO Adapter

Command and Coding enhancements requested by users
  Improvements to the if statement (else, else if, nesting)
  Create Graphs and Charts from GUI commands
  pic, picq, xpic for pictures over serial
  cirs for filled circle
  rest command to reset Nextion device
  addt to add multiple waveform values
  cov command to convert .txt to .val
  Component show/hide (vis command)
  Global support to change value on another page
  Component touch enable/disable (tsw command)
  Inc/Dec counter solely within Nextion HMI
  Send x,y touch coordinate over serial (sendxy variable)

Component enhancements requested by users
  password masking
  on-screen keyboards
  enable/disable component touch (tsw command)
  trigger component event (click command)
  Checkbox and Radio Buttons implemented
  Barcharts (fill command and Progress Bar)
  backgrounds of solid colors/crop image/image
  Scrolling Text marquee component
  Number component to support negative and positive
  Text with solid background color
  Added .txt attribute to Dual State
  Letter spacing (.spax and .spay)
  Multiline support

Arduino support (big difference in 0.70 and 0.90)
  more access to attributes
  change component colors over serial
  Ongoing increases of Iteadlib’s capabilities, the effort continues
  Raspberry PI supported via Itead’s Segnix and Iteadlib

 


But perhaps when one wants to bash Nextion without understanding

   there is a level of "right back at you" that is indeed deserved.

For those that bothered to use the Search Bar to look for related topics

   they would have seen I already let the cat out of the bag (Jun 7, 2017)

   (should not have) that some of these functions are up and coming ...

   http://support.iteadstudio.com/support/discussions/topics/11000013640


When one starts bashing Nextion because one doesn't bother to read ??

    I'm sorry, but I just can't help but indeed respond.


When one doesn't get their way

  - make a statement we don't listen to users ... just the wrong way


Some customizations can even be discussed when commitment is given

  - and by commitment given  ... is when order completes

    not on future hopes and dreams, but on actual quantity purchase

  - (quantity purchase in China is not defined as 1 dozen for the record)

So, much of the "Itead doesn't listen" is customer didn't want to pay for.

and just to mention ...

"It's not a competition to see who knows more or has a bigger ego."

   - surely no competition, but more like a question of plain knowledge ...

"bitwise operators, especially XOR, AND, and OR operators. This is only to allow a minimal encryption in communicatios (not with few effort with processing in the nextion side)."

    - this and much more can already be done ... you only must do it ...

 

tft
Login or Signup to post a comment