关于消费电子设备的安全性，OMTP几年之前就开始了相关的工作，主要是定义了已被识别的设备的安全威胁，以及给出了可信环境的概念。工作的成果体现在几个文档上：
OMTP Security Threats on Embedded Consumer Devices
OMTP Trusted Environment OMTP TR0
OMTP Advanced Trusted Environment OMTP TR1
从文档命名上可以看出，一个是安全威胁描述，另一个是可信环境，而后者由分为两个级别：TR0和TR1，TR0是比较基本的，TR1的安全性则更高一些。
安全威胁方面，从攻击所需专业性、重复难度和传播难度三个方面进行了考量，从专业性上，容易：用户自己可以实现；中等：需要专业知识；难：需要专业知识和价格昂贵的设备。重复难度：容易：用户自己就可以重复；中等：需要到后街商店；难：需要专业知识和昂贵设备。传播难方面，WWW：攻破之后，通过互联网就可以传播，这种情况最糟糕；小公司：小公司可以使用信息/传播安全漏洞；大公司：大公司可以使用信息，比如克隆手机。
威胁分类：
软件修改威胁SWM：UE软件修改。关注特权代码的修改。
软件机会主义威胁SWO：针对软件定义或者实现中的弱点，可以暴露UE的秘密或者使其不正常或非授权地工作。关注如缓冲区溢出、突破访问控制的攻击。
硬件威胁--外部HWE：不破坏终端的完整性，通常通过UE外部的端口或者连接线来实施。
终端注入HWT：物理威胁，要打开UE的外盒，包括探测PCB的总线或者挂在PCB上的packege的引脚。它包含物理上移除某个组件，而该组件的完整性不会被破坏。
硬件组件攻击HWC：会影响到组件的物理完整性的威胁或攻击，包含但不限于SoC，内存和PCB。它包含物理上移除某个组件，而该组件的完整性会被破坏。
硬件克隆，组件替换，组件增加CLO：替换UE的一部分或者整个UE的威胁。包含但不限于替换SoC或内存，以及生成一个UE的拷贝。
注意这里的威胁主要是针对系统和硬件的，并没有特别针对某个应用，比如在android中，应用访问通讯录的API是开放的，用户在应用安装的时候同意这种访问权限，应用就可以访问了。从计算机安全的角度来看，是否能防范缓冲区溢出，是否能防范获取系统特权才是其所关心的重点。对于窥探用户隐私的应用的防范，则需要在保证系统安全的基础上，定义特定的资产（比如通讯录，通话记录等），然后再对这样的资产实施相应的保护机制（如访问控制）。但是这样的安全需求还不是OMTP关注的重点。
OMTP TR0是比较基本的可信环境需求的描述。所关注的威胁，主要是非安全的软件攻击，调试端口的攻击，不破坏设备物理性的硬件攻击（如芯片间通信信号的探测），更换数据存储元素或修改其内容等；不包含芯片级别的攻击（如芯片探测），旁路攻击（电源，时序等），在芯片间总线写入等。
可信模型的基础是安全属性，包括真实性，完整性和保密性，以及授权方。硬件资源就可以包含：完整性保护的硬件，保密性保护的硬件，兼具完整性和保密性的安全硬件，以及安全存储（也包含完整性的保密性的属性），以及运行时要检查完整性的存储等。而存储的安全属性的保护又可以由普通OS，安全OS以及硬件分别来完成，也就是说，这是一个多级安全的可信模型，从底层到上层，分别有硬件、安全OS和普通OS来分别完成其安全责任。类似的，软件则定义了已被认证软件，授权软件和受保护的软件，以及普通软件。
安全需求分为总体安全需求，调试端口保护，移动设备ID，SIMLock，DRM，安全启动，安全绑定，安全Flash更新等需求。这是针对TR0列出的威胁模型，所需要满足的需求。比如，对于硬件唯一密钥(Hardware Unique Key)，要求一个ME首先要支持一个HU密钥，然后规定密钥应该如何产生，应该被谁访问，是否可以修改，密钥长度至少是多少，密钥的用途是什么，对于保密性，完整性，真实性的保护，应采用什么样的算法和加密强度等。再比如，对于安全启动的需求，可以认为在硬件控制完整性的存储中的组件是经过了验证的（就是安全ROM中的loader），然后这个loader装载后续的软件组件的时候，都要对其做完整性和真实性验证，这样就形成了一个安全启动链，从根开始一级一级地验证并加载组件，以保证整个系统的安全。对于需要保证的是：boot loader的真实性和完整性；如下资产的真实性和完整性：移动设备的ID，报告和保护移动设备ID的软件组件，实现SIMLock机制的软件组件；操作系统核的真实性和完整性。这其中有些是硬件完成，有些由软件完成，即上面提到的分级安全。
OMTP TR1的威胁模型比TR0要具体和复杂些。除了前面考虑的威胁类别，还特意强调了：
用于访问内存的硬件模块，比如一个DMA模块，可以不通过CPU而直接去访问某些资产，也不会被MMU的用户/特权模式所限制；
用于显示内存和交互数据的CLCD；
通过移除电池或移除外部存储卡的方式来绕过安全。比如在设计得不好的DRM方案中，当播放歌曲到最后才减少播放权限次数，如果权限次数存放在外部存储卡中，就有可能通过移除外部存储卡来获得无限次的歌曲播放；
设备关机时替换Flash芯片，这就可能把整个存放在flash中的安全路线完全替换掉；
通过总线监控来获取秘密；
修改外部RAM中的内容；
设备开机时替换Flash芯片，比如两个几乎一样的flash芯片，其中一个是有真实性保证的，在设备运行的某个时刻使用没有真实性保证的flash将其替换，两个flash的内容基本一致，除了其中的DRM权限对象。
TR1的安全需求又分为profile1和profile2，后者比前者要更加高级一些。TR1从如下几个功能模块来描述：安全存储，可信执行环境（TEE），灵活的安全启动，GBA，运行时完整性检查，与UICC（安全元素，SE）的安全交互，安全用户输入输出。
安全存储是在终端上保存敏感对象，保护其完整性和保密性的推荐机制，主要保护数据和密钥。
可信执行环境提供安全的软硬件设施来支持应用的安全执行，保护诸如内存管理，执行和应用程序管理，执行环境的交互，API等，在设备中处于一个很低的层次，注意它和普通的执行环境（比如Android）是分离的。
运行时完整性检查是确认设备所做的事情正是其该做的事情，以及关键数据的完整性保证机制。它保护如IMEI，SIMLock状态等。
安全用户输入输出确保呈现给用户的任何东西都是真实的，而不是被恶意软件篡改过，以及用户输入不被窃取。其实国内银行的二代key就是完成了这个保护。
GBA本来是一个框架，用来在USIM和运营商之间建立安全联系，目的是为应用层服务，比如SP可以从运营商请求密钥来与用户的USIM建立联系以提供服务。在终端上的密钥访问，存储机制等均需要安全保护。
灵活安全启动比TR0而言，最大的区别就是增加了启动代码是可以更新的。
与UICC的安全交互，保证了设备与UICC之间的数据传递是安全的而且能防范其被修改。
为实现以上描述的安全需求，首先需要芯片级别的支持，芯片能够提供诸如HU密钥的保护机制，然后就是在软件上考虑如何充分利用硬件支持的特性，设计合适的安全方案和安全机制来满足安全需求，比如数据和密钥存储在什么地方，代码的完整性如何验证，应用的认证性如何验证，应采用几级密钥体系等，这是一个复杂又渐进的过程。