Hi John:
Your example is, as described by Doug Nix, defeat resistance, not tamperproof (see the definitions). Tampering cannot be safeguarded, except, maybe, with a safe (which is also defeat resistant). đ Best regards, Rich From: John Woodgate <j...@woodjohn.uk> Sent: Tuesday, April 9, 2019 11:25 AM To: ri...@ieee.org; EMC-PSTC@LISTSERV.IEEE.ORG Subject: Re: [PSES] Tamper-proof Hardware 'Tamperproof' is like 'fireproof' or 'foolproof' - a pure illusion; misplaced human ingenuity knows no bounds. But measures against successful tampering are surely not outside the scope of safeguarding. For example, a soda-machine has parts designed so that they can be assembled together with a screw-thread, but an attempt to unscrew breaks the parts so that they can't be reassembled. This prevents the machine exploding under carbon dioxide pressure if the re-assembly was incorrectly carried out. Best wishes John Woodgate OOO-Own Opinions Only J M Woodgate and Associates www.woodjohn.uk <http://www.woodjohn.uk> Rayleigh, Essex UK On 2019-04-09 19:04, Richard Nute wrote: Standards need not â indeed should not -- address nefarious activity on the part of the user. And, standards need not address tampering (defined previously) as there can be no end to the extent of tampering. The requirement for âtamperproofâ is beyond the scope of safeguarding a user through applications of safeguards against energy sources. Rich From: John Allen <mailto:john_e_al...@blueyonder.co.uk> <john_e_al...@blueyonder.co.uk> Sent: Tuesday, April 9, 2019 1:11 AM To: <mailto:ri...@ieee.org> ri...@ieee.org Cc: <mailto:EMC-PSTC@LISTSERV.IEEE.ORG> EMC-PSTC@LISTSERV.IEEE.ORG Subject: RE: [PSES] Tamper-proof Hardware Rich Thanks for laying out the main definitions of âtamperproofâ, and for your view on why my âstoryâ is not an example thereof (it was only the one that I had âto-handâ at the time, and there must be many others :)) . Maybe, therefore, similar definitions/explanations should have been included in IEC 62368, so as to make it (much!) clearer to designers and testing/certification personnel as to the intent of the requirement because (obviously) there can be a considerable spread of interpretations of the requirement - or else John Cochran (and probably many others!) would not ask the question. As it stands, that ârequirementâ must thus be considered to be âambiguousâ at best, and therefore shouldnât have been included in a standard in that form (Iâm sure there must be a word to describe a definition with four different possible interpretations, but Iâm afraid I donât know it and thus âambiguousâ is the best that I can offer ATM!). In fact, given the definitions you quote, I would suggest that the term should NOT have been included in the standard at all because they imply the likelihood of various levels of intentional interference/criminality on the parts of possible perpetrators. However, it should not have been the intent of the 62368 standards-writing teams to address such issues - maybe YES if it were in a theft/ building-intrusion/ forgery prevention (etc.) standard, but NO in a broadly-targeted product safety standard. John E Allen W. London, UK - ---------------------------------------------------------------- This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. To post a message to the list, send your e-mail to <emc-p...@ieee.org> All emc-pstc postings are archived and searchable on the web at: http://www.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe) List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <sdoug...@ieee.org> Mike Cantwell <mcantw...@ieee.org> For policy questions, send mail to: Jim Bacher: <j.bac...@ieee.org> David Heald: <dhe...@gmail.com>
