array和slice的概念

数组（array）是一组拥有相同类型 T 的对象的集合，在内存中是连续存储的。数组使用中括号 [] 来创建，且它们的大小在编译时会被确定。数组的类型标记为 [T; length]（T 为元素类型，length 表示数组大小）。

切片（slice）类型和数组类似，但其大小在编译时是不确定的。相反，切片是一个双字对象（two-word object），第一个字是一个指向数据的指针，第二个字是切片的长度。这个 “字” 的宽度和 usize 相同，由处理器架构决定，比如在 x86-64 平台上就是 64 位。slice 可以用来借用数组的一部分。slice 的类型标记为 &[T]。

字节数组的几种类型：

(一)      [u8; N]（固定大小的字节数组）
这是一个固定长度的数组，长度 N 在编译时确定。
存储在栈上（stack），如果数组过大可能导致栈溢出。
拥有数据的所有权。
大小无法在运行时改变， 如果需要改变，只能释放了再新建。
访问时可以使用 & 获取切片（&[u8]）

(二)   &[u8]（字节切片 引用）
动态大小，存储在堆上或栈上，通常是借用（reference）。
可通过 as_ref()、deref() 或 slice::from_ref() 从数组转换。
它是一个对字节序列的不可变引用，可以指向[u8; N] 或Vec<u8> 等的一部分
不拥有数据，仅借用；长度在运行时确定。

切片本身 不拥有 任何数据。它只是指向已存在字节数据的指针和长度。数据的所有权属于切片所引用的原始数据。
切片的大小在运行时确定，由其指向的数据的长度决定。

(三)   &mut [u8]（可变字节切片）
和 &[u8] 类似，但允许修改数据

(四)   Vec（动态字节数组）
可变长，存储在堆上（heap）。
适用于需要增长或缩短的字节数据
拥有数据的所有权，可以动态调整大小
允许 push、resize、extend 等操作。
通过 push, pop, insert, remove 等方法进行增删元素

(五)  Box<[u8]>（堆分配的字节数组）
固定长度的堆分配数组，与 Vec 类似但不可变长。
适用于数据不需要增长的情况，但仍希望存储在堆上。
let boxed: Box<[u8]> = vec![1, 2, 3, 4].into_boxed_slice();
拥有所有权，在堆上分配，大小固定但可以在运行时创建

(六)   Cow<[u8]>（惰性克隆的字节数组）
Cow（Copy on Write，写时复制）适用于既可能是借用的（&[u8]）也可能是拥有的（Vec）数据。
适用于优化性能，避免不必要的复制，只有在需要修改时才会克隆数据。

(七) [u8] 未定大小的字节切片
这是一个抽象的字节切片类型，通常在泛型或 trait 定义中使用。
无法直接实例化，仅作为类型参数出现。
是一个视图（view）而非拥有数据的类型

(八) String和&str
用于文本字符串，以UTF-8编码的字节。本质上也是字节序列。
String拥有数据， &str是一个切片引用。

在某些情况下，你可能会将 String 或 &str 视为字节数组来处理，例如在处理 ASCII 文本或进行底层字符串操作时。但要注意，它们强制 UTF-8 编码，可能不适合处理任意二进制数据。

转换：
[u8; N] 可以转换为 &[u8] 或 &mut [u8](用 &符号 借用)
&[u8] 可以转换为 Vec（ 用.to_vec()复制为Vec<u8>）
Vec 可以转换为 Box<[u8]>（比如上面的介绍的into_boxed_slice()）
&[u8] 或 Vec 可以转换为 Cow<[u8]>
Vec<u8> 可以通过 .as_slice() 转为 &[u8]
&[u8] 转化 &[u8; N] , 用 try_into()

注意事项：
&[u8] 和 Box<[u8]> 是不可变的（除非使用内部可变性如 Cell 或 RefCell）
&[u8] 和 &mut [u8] 长度由引用的数据决定

文件标识符(FID)用来定位和识别一个特定的文件。
同一父目录下的任何两个文件都不应具有相同的FID
当前目录的子文件或者子目录，当前目录的父目录， 当前目录的兄弟目录，这三者不能有相同的FID
短文件标识符 (SFI) 编码为 5 位，取值范围为 1 至 30。同一父级下的任何两个文件都不应具有相同的 SFI。
保留的 FID–7FFF可用作给定逻辑通道上当前活动应用程序的 ADF 的 FID。
DF除了有FID外，还可以有名字，名字就是AID, AID在每张卡上都应该唯一。 AID的长度，从1到16个字节。
——
在 UICC 激活和发送ATR给读卡器或者modem后，主文件 (MF) 被隐式选择，并成为当前目录。
(1) 通过FID应用来选择文件或者目录
选择 DF、ADF 或 MF, 都会改变当前目录， 当前EF为空，也就是不存在当前EF
选择EF, 会改变当前EF,但不会当前目录， 目录还是之前的目录，并且这个目录就是当前EF的父目录。

通过文件FID, 可以选择
[1]当前目录的直接子级的任何EF文件
[2]当前 DF 父级的直接子级的任何DF, 也就是当前目录任何兄弟DF
[3]当前目录的父级
[4]当前 DF
[5]当前活动应用的ADF
[6]MF, 也就是3F00
(2)通过 路径 来选择
路径 有3种模式：
[1] 从MF开始
[2] 从ADF开始
[3] 从当前DF开始
MF模式下，终端不得在路径开头使用 MF 的文件标识（即3F00）。
当前DF模式下，终端不得在路径开头使用特殊文件 ID–7FFF。
MF模式或者当前DF模式，终端不得使用当前 DF 的文件标识， 也不得使用空数据字段（也就空选择）。

———-
通过使用 AID 显式选择应用，就可以激活应用，并把选择的应用的 ADF 设置为当前 ADF。
当前 ADF 可以通过 FID 引用，隐式引用值为 7FFF

一个可以被选择的应用，可以通过部分DF名称模式选择，此时应该将P1 设置为 ’04’。部分选择的情况下，DF名称被右截断。
如果卡上有多个应用，它们的AID的开头的内容相同，如果采用部分DF名称模式，具体应该选择那个AID,应取决于P2值。如果P2的值表示”last”,那么选择的应该是与部分 DF 名称匹配的最后一个活动应用。

对于单应用卡，使用部分 DF 名称选择应用是可选的，但多应用卡应支持 部分DF名称选择模式。卡应该在ATR 历史字节的”卡服务数据”和”卡功能”压缩 TLV 对象中指示对此功能的支持.

如果 UICC 不支持使用部分 DF 名称进行选择，则 UICC 应以适当的响应进行响应（例如，不支持命令参数6A86）。
—————–
P1
00 通过FID选择DF, EF 或者 MF
01 选择当前DF下的子DF
03 当前DF的父DF
04 通过DF的名称（也就是AID）来选择
08 通过从MF开始的路径 来选择
09 通过从当前DF开始的路径来选择

如果 P1 = ’00’ 且数据字段为空，则应将 P2 设置为 ‘0C’（“无数据返回”）。然后，MF 被设置为当前目录。

为避免 P1 = ’00’ 时出现歧义，在选择以文件 ID (FID) 为参数的文件时，应遵循以下搜索顺序：
[1]当前 DF 的直接子文件
[2] 父 DF
[3] 父 DF 的直接子文件

当 P1 ≠ ’04’ 时，P2 的位 b2 和 b1 没有意义，应设置为 0。
当 P1 = ’04’（即通过 AID 选择）时，可以在数据字段中指定右截断 AID。

P2=04, 要求返回FCP模板
P2=0C, 不要求返回数据

之前用的是双不限流量卡，访问国外网络还比较快

换成宽带之后，访问rust网站明显变慢。

rust官方介绍的安装方法

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

几乎无法安装。

改成如下命令即可

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs > rust.sh
sed -i 's|static.rust-lang.org|mirrors.ustc.edu.cn/rust-static|g' rust.sh
export RUSTUP_DIST_SERVER=https://mirrors.tuna.tsinghua.edu.cn/rustup
chmod a+x rust.sh
./rust.sh
安装完成后
echo "RUSTUP_DIST_SERVER=https://mirrors.tuna.tsinghua.edu.cn/rustup"  >> ~/.cargo/env

李宏平 孟玉明 张立星 张傲思 杜琳美
1 联通华盛通信有限公司 北京 100032
2 全国海关信息中心 北京 100005

引言
现有实体SIM卡写卡有以下两种方式:一种是通过写卡器将卡数据写入SIM卡内,此种方式SIM卡与设备是物理接触,不需要进行在线认证就能保证将卡数据写入正确的卡内;另一种是空中写卡方式,运营商通过卡内预置的号码给卡发送数据短信,将卡数据传递到卡内,SIM卡与运营商之间通过预置号码的网络参数进行认证来保证卡数据写入正确的终端内。
eSIM以密码学技术为基础,使运营商签约数据在生产、存储和递送环节与硬件分离,以电子数据的形式存在,支持通过网络远程配置到终端。在这种情况下,eSIM终端出厂前无法确认需要支持的运营商;同时也存在一个终端上可存储多个电子卡数据的情况,这些电子卡数据可能来自不同的运营商,这就会导致终端和管理平台不知道对方各自的情况。
一般来说,网络上的实体间采用数字证书的方式来进行在线的相互认证。GSMA使用PKI(Public Key Infrastructure)公钥证书体系作为eSIM安全机制的基础[1]。eSIM平台RSP(Remote SIM Provisioning,远程SIM卡数据配置)业务数字证书由eSIM CA系统签发,可作为eSIM设备和服务器在RSP业务中的身份标识,实现设备认证、服务器认证以及信息传输的完整性和抗抵赖性。

1 数字证书与eSIM安全机制
1.1 eSIM技术架构
GSMA是eSIM标准的主要研究机构,从2011年至2016年先后发布了4个版本的eUICC标准,主要面向行业物联网市场。为了将eSIM的适用范围拓展至公众消费设备,GSMA又于2016年发布了远程SIM卡数据配置(RSP)标准。RSP采用的是客户端驱动模式,适用于可穿戴、平板电脑等消费类电子产品,针对用户自签约、自配置、自管理的特点进行了优化。
为了实现eSIM的业务需求,RSP技术标准定义了一套包含管理平台、终端、eUICC、CA以及相关配套设施的技术体系[2],如图1所示。

主要实体包括以下6种。
1)Profile:运营商向用户提供服务所需的卡数据和卡应用的集合,需要通过空中下载的方式安装到eUICC上。
2)eUICC:Profile的硬件载体,类似于传统USIM卡的UICC,但软硬件更复杂,可满足动态加载运营商数据的需要。同一张eUICC上可以加载属于不同运营商的多份Pro fi le,但同一时间只有一份能使用。
3)SM-DP+:负责生产、存储、提供Profile的网络服务平台。SM-DP+需具备必要的软硬件能力以确保Profile的安全。
4)终端:需要接入移动网络的实体。eUICC预置在终端中,终端也负责从SM-DP+下载Profile并写入eUICC。
5)DS:发现服务器,协助终端寻址SM-DP+。
6)CA:标准PKI证书权威机构,为体系内的通信各方颁发可信数字证书。

1.2 RSP标准的安全机制
eSIM采用基于公众网络的空中写卡技术,面临Profile数据泄露、Profile被窃取等网络威胁及安全风险。GSMA RSP标准

中提供了一系列安全机制和工具,用于防止Profile在下载、存储等环节的安全威胁[3]。RSP标准要求eSIM在生产、管理、安装、使用等任何环节的安全级别不低于传统可插拔SIM卡,体系中各实体需通过GSMA定义的安全认证。在技术层面,RSP标准也定义了多种安全机制来确保安全性[4],如表1所示。

2 eSIM数字证书管理
2.1 证书分类
eSIM系统中的PKI证书体系分为三个层次:根证书、卡商证书/平台证书、eUICC证书。其中根证书是自签名证书,是信任链的起始点。EUM证书(Embedded UICC Manufacturer)也叫卡商证书,由根证书签发,eUICC证书由EUM证书签发。服务器证书也由根证书签发。RSP业务中所有的证书均为X509格式证书。

2.2 证书链
RSP标准定义的证书链如图2所示。

2.3 证书签发

eSIM管理系统中各个实体的证书管理需要符合PKI架构要求。CI 根证书、卡商证书、平台证书(SM-DP+证书及 SM-DP+ TLS 证书)需要由运营商认可的CI签发,但是允许SM-DP+证书与SM-DP+ TLS 证书可以由不同的CI签发。eUICC证书由卡商使用二级根证书签发,eUICC需要认证eSIM下载服务器的DP+公钥证书。

2.4 证书系统实现
eSIM CA系统由离线CA、在线CA、RA、OCSP组成[5]。离线CA是一个单独的、可信任的根CA,它生成CI根证书,并通过CI根证书签发卡商EUM证书和服务器证书。在线CA即EUM,其核心功能就是签发和管理eUICC证书,EUM具有证书发放、证书更新、证书撤销和证书验证的功能。RA (Register Authority)是面向用户的审核受理机构,负责审核终端实体的相关信息,负责维护用户的信息。通过证书中的OCSP (Online Certificate Status Protocol)服务器地址,使用在线证书状态查询服务。

证书有效性验证包括三个方面内容:
1)验证证书中的签名,确认证书是由CA签发的以及证书的内容没有被篡改;
2)检验证书的有效期,确认该证书在有效期之内;
3)查询证书状态,确认该证书没有被注销。

在进行证书验证时,逐级验证签发者直至根证书。根证书的验证通过自身公钥来验证其签名信息,CA证书验证通过根证书的公钥来验证证书的签名,用户证书验证通过相应CA证书的公钥来验证证书的签名。在验证过程中,需要判断证书是否在有效期内。

2.5 证书生命周期
证书签发下来后状态默认为有效态;当证书处于不安全状态时,可以进行冻结操作,证书状态改为冻结态,冻结态证书可以通过解冻操作恢复为有效态;有效态证书和冻结态证书均可以做吊销操作,使证书改为作废态,吊销后的证书不能改变状态。

证书的整个生命周期如图3所示[6]。

CI签发的各种证书应设置有效期,超过有效期的证书应停止使用。eSIM下载服务器会检查eUICC证书、EUM证书的有效期,超过有效期的证书将被拒绝访问。

3 数字证书在eSIM平台上的应用
eSIM管理平台的主要功能是卡数据的生成、管理以及下发。在卡数据下发之前,管理平台与RSP终端需要进行相互认证之后,才能将卡数据下发到RSP终端中的eUICC卡内。有时,RSP终端内会预置多个不同CA签发的不同根的证书,同样,管理平台也会预置多个不同CA签发的不同根的证书,在用户使用RSP终端选择运营商办理好业务之后,RSP终端可以根据运营商发来的信息访问到管理平台,通过相互认证之后管理平台将卡数据下发到RSP终端上。

管理平台与RSP终端间的相互认证过程如下:
1)当RSP终端需要进行认证时,向管理平台发送认证请求,该认证请求包括RSP终端中eSIM支持的eSIM证书的标识;

2)管理平台接收到认证请求后,在管理平台查找与eSIM证书的标识一致的DP证书,并根据认证请求中的eSIM随机数和生成的DP随机数获得DP签名体,并对DP证书和DP签名体进行签名获得DP的签名;

3)管理平台将DP证书的标识、DP证书、DP签名体和DP签名一并发送给RSP终端;

4)RSP终端接收到上述数据后,用与DP证书标识一致的eSIM证书的公钥对所述DP证书进行验证,若验证失败,则RSP终端向管理平台向发送验证失败消息,如果验证通过,则RSP终端进一步用DP证书的公钥对DP签名进行解签,并将解签后的DP签名与DP签名体进行比对,若比对一致,则RSP终端将DP随机数和eSIM的信息一起打包生成eSIM签名体,并对该eSIM签名体进行签名获得eSIM签名;

5)RSP终端向管理平台发送eSIM证书、eSIM的EUM证书、eSIM签名体和eSIM签名;

6)管理平台根据DP证书对接收到的eSIM证书和EUM证书进行验证,若验证通过,则管理平台用接收到的eSIM证书的公钥对eSIM签名进行解签,并将解签后的eSIM签名与接收到的eSIM签名体进行比对,如果比对一致,则认证成功完成本次认证。

其中,进行签名的步骤可以由管理平台自身进行签名,也可以单独授权给独立的模块进行签名。例如单独设置加密机,管理平台将需要进行签名的数据发给加密机进行签名,并获得加密机返回的签名。如果RSP终端的eSIM支持多个eSIM证书,则针对每个eSIM证书都按照上述流程提供的认证方法进行认证,从而实现RSP终端的多运营商支持功能。

4 多证书管理现状及发展趋势
4.1 多证书
选择合适的证书服务是保障运营商数据安全的关键。eSIM证书服务既要符合GSMA标准,又需满足政府监管要求,目前国际上提供证书服务的主要两家:CyberTrust、Symantec。GSMA特别准许国内运营商自己选择CI,CA证书签发者必须是工业与信息化部公布的具有电子认证服务行政许可的认证机构,目前,三家运营商各自有CA,国内的电信终端产业协会(TAF)也是具备为eSIM平台及EUM颁发证书的CA。

RSP标准基于PKI的信任机制允许eUICC同时访问多个eSIM管理平台,理论上eUICC上只需要安装一张证书就可以,但这只是理想状态。例如美国Verizon和AT&T互不使用对方的证书。为了解决这个问题,RSP标准定义了多证书机制,eUICC中可以同时安装多张CA证书,按需使用。eUICC应能支持多个根证书,eSIM下载服务器也应能支持多个根证书,并能根据eUICC支持根证书的情况选择合适的证书。

4.2 GSMA统一根证书策略分析
为了实现全球互通,GSMA希望根证书统一由经过认证的CA签发,但为了满足各国政府监管需要,GSMA在SGP.28规范定义了两种CI:GSMA Root CI和Independent Root CI。

根据GSMA 规范要求,CI选择需要考虑的因素包括:
1)公司制度完善;
2)有能力对申请证书的企业的资质进行验证;
3)有能力保护整个生态体系;
4)积极参与eSIM发展;
5)能证明产品质量;
6)具备CI领域的知名度;
7) 产品覆盖广度(建议至少被8个运营商支持);
8)产品覆盖的区域(建议至少在2个以上区域使用);
9)具备长期服务的能力;
10)符合技术规范;
11)对各厂商中立无歧视;
12)签发证书的效率。

根据国内运营商发展现状,国内运营商提出针对GSMA的部分条件应当允许适当调整,如:为保证尊重运营商平等选择权利,只要有一家运营商推荐即可申请成为CI;对CI申请评估应该注重技术性因素,综合考虑市场规模因素,而不是运营商个数;覆盖多少国家、有多少运营商支持不应成为对CI的准入要求;签发证书的历史长短不应成为对CI的准入要求等条件。同时,为解决全球互通,减少eUICC需要安装的CA数量,降低DP+平台安装多个CA所需的成本,GSMA需要提供一个完整的CI解决方案,在该方案中应该体现如下原则:

1)多个CI组成CI包(CI Package) ,以实现对多个监管地区的覆盖;
2)对于每个监管地区,都需要有至少1个被该地区法律认可的CI在包中;
3)DP+需支持包中的所有被其所在地区认可的CI(不能选择性支持),eUICC则只需选择其中一个CI(需要支持跨区域时需每个区域选择一个CI);
4)建议GSMA在认证CI时一并解决CI的商务问题,DP+平台可以合理的价格获得并安装该监管地区内所有CI颁发的证书。

4.3 国内CA管理策略研究
由于国内运营商的eSIM平台均采用自建的技术路线,在证书服务选择上,终端厂商及卡商的话语权较弱,国家相关管理机构也未明确政策意见,因此目前仍由运营商自主选择为主。同时,中国三家运营商互不使用对方证书,这导致终端eUICC需预置多家证书,提升了终端复杂度,也不符合GSMA对统一根证书的管理原则。
国内CA管理需要一套互联互通方案,在设计时应考虑符合中国法律和监管要求、保证终端可以与各家运营商的DP/DP+互通、eUICC上只需安装一个CA就可以连接全部运营商的DP/DP+、需要具备商业上的公平性、合理性和可行性。基于此,我们提出如下三种可行方案。表2对三种方案做出了比较。

CI方案	优点	缺点
公益性单CI	监管简单，只需要管理一家CI; 产业链成本低； 对各厂家相对公平	缺少商业驱动，服务质量不能保证； 对新技术新业务不能提供很好的支持
运营商互认多CI	eUIIC侧 通过市场公平选择; 运营商背书保证CI服务质量； 对CI的管理与对运营商的管理合二为一	平台需支持多CI
市场化多CI	通过市场公平选择; 通过竞争，CI服务质量较有保证	平台需要支持多CI,管理相对复杂; 实力差的企业可能因市场变化无法提供长期的技术支撑

4.3.1 公益性单CI方案
由监管部门指定一个CI作为统一CI,该CI需要是公益事业性质,由政府提供资金支持,不对运营商(平台证书,包括TLS证书)、eUICC厂商(EUM证书)收取费用。

4.3.2 运营商互认多CI方案
1)由监管部门组织统一CI入围招标,入围厂家数量可控制在3家左右。
2)平台证书免费。所有CI无歧视地向个运营商签发平台证书,所有运营商需要无歧视地支持各个CI的证书。
3)eUICC只需要安装一个CI的证书,由eUICC厂家自主选择用哪个CI,eUICC厂家与CI厂家自主进行商务谈判。

4.3.3 市场化多CI方案
1)由监管部门组织统一CI入围招标,入围厂家数量可控制在3~4家左右。
2)平台证书免费。所有CI无歧视地向个运营商签发平台证书,所有运营商需要无歧视地支持各个CI的证书。
3)eUICC只需要安装一个CI的证书(但不限制安装数量),由eUICC厂家自主选择用哪个CI,eUICC厂家与CI厂家自主进行商务谈判。

5 结语
eSIM是对移动通信技术的一次重大改进,使通信服务摆脱了SIM卡线下发卡环节的束缚,可实现全面互联网化的业务流程,让用户获得随需、即时入网的极致体验。终端商则得以摆脱卡槽束缚,优化产品外观并提升性能,如减小体积、增加电池续航、增强防水能力等,为广大消费者带来更多、更好的产品。

随着智能手表等可穿戴设备在国内的普及,eSIM技术在移动通信业务中扮演的角色越来越重要,其安全性问题深受产业链各方的关注。eSIM采用基于公众网络的空中写卡技术,为解决Pofile在传输过程中的安全性,采用了一套基于PKI的同根数字证书作为eSIM设备和服务器的身份标识。目前国内各运营商已确定使用自建的eSIM平台进行业务发展,对eSIM平台上的数字证书应用与管理必将引起更多重视,数字证书颁发机构之间的互相认可也将成为值得研究的新课题。

移远5G模块，开启adb, 需要输入一个key来开启

import crypt

#sn = '18700338'
#sn = '40901409'
sn = '12741851'


def generateUnlockKey(sn):
    """
    @param sn: the serial number to generate an unlock key for
    """
    salt = "$1${0}$".format(sn)
    c = crypt.crypt("SH_adb_quectel", salt)
    print("Salt: {0}\nCrypt: {1}\nCode: {2}\n".format(salt, c, c[12:27]))
    return c[12:27]
    
    
xx = generateUnlockKey(sn)    

print(xx)


def old_key(salt):
    code = crypt.crypt("SH_adb_quectel", "$1$" + salt)
    #code = crypt.crypt("SH_adb_quectel", "$1$" + salt + '$')
    code = code[12:27]
    
    return code
       
       
yy = old_key(sn)    

print('jiandan=', yy)     

2G GSM

3G UMTS/WCDMA

4G LTE

跟C++的版本 ， 操作系统， 编译器关系非常大

当字符串长度>16时
第1个 int64 保存着 buf的地址

对于电信2020年后发行的普通SIM卡和物联网卡，是没有CDMA所需要的CSIM文件的。早期的EC20为了适配当时的电信UIM卡，是做了特殊处理的，启动后会搜寻SIM卡中的CSIM文件，没有这些文件就不会注册到网络。

解决方法：
（1） 读取nv 配置

发送AT命令给EC20模块

AT+QNVFR="/nv/item_files/modem/mmode/operator_name"

读出来的结果应该是 01
(2) 将该配置改为 00

AT+QNVFW="/nv/item_files/modem/mmode/operator_name",00

(3) 插入 电信4G物联网卡，断电重启EC20

说明:
operator_name = 00 表示 OPERATE_NULL, 选网时采用默认设计，无特定运营商
operator_name = 01 表示 OPERATE_CT, 中国电信，选网时是考虑CDMA兼容，SRLTE（CDMA+LTE双在网)等需求

在一款 2017年出厂的EC20上实测成功， 版本为 EC20CEFAGR06A05M4G

Phone connects to Edge Packet Data Gateway (EPDG)
over WiFi
• Voice calls over WiFi
• Phone connects on low/no signal
• Also connects in Airplane mode + WiFi

Connection to EPDG uses IPsec
• Authenticates using Internet Key Exchange Protocol (IKEv2)

Internet Protocol Security
• Confidentiality, data integrity, access control, and data source
authentication
• Recovery from transmission errors: packet loss, packet replay, and
packet forgery
• Authentication
• Authentication Header (AH) – RFC 4302

• Confidentiality
• Encapsulating Security Payload (ESP) – RFC 4303
• Key management
• Internet Key Exchange v2 (IKEv2) – RFC7296
• Two modes
• Tunnel – used for connection to Gateway (EPDG)
• Transport

Internet Key Exchange (IKEv2)
• Initiates connection in two phases
• IKE_SA_INIT
• Negotiate cryptographic algorithms, exchange nonces, and do
a Diffie-Hellman exchange
• IKE_AUTH
• Authenticate the previous messages, exchange identities (e.g.
IMSI), and certificates, and establish the child Security
Association(s) (SA)
• IKE_AUTH uses EAP-AKA
• IMSI exchange not protected by a certificate
• Open to MitM attacks on identity (IMSI)

IPsec ESP keys are not compromised
• Call content still safe

小米firmware下载的cdn 限速了。
据说是因为一帮搞 pcdn的人，为了让自己的上行流量占比 小一点， 故意刷下行流量。 其中小米firmware的下载地址是很好获取的，所以被狂刷了很多流量。
其实没什么用，现在运营商不是看占比， 而是上行流量超过多少G，就停宽带。
这帮人做一些损人不利己的缺德事：小米付出了不应该的流量费用，普通用户获得了糟糕的下载体验; 他们的宽带还是被运营商停了。

默认的地址是 bigota.d.miui.com, 改成

cdn-ota.azureedge.net
cdnorg.d.miui.com
bn.d.miui.com
bkt-sgp-miui-ota-update-alisgp.oss-ap-southeast-1.aliyuncs.com

有时候可以提高下载速率

https://bn.d.miui.com/V12.5.15.0.RGGEUXM/begonia_eea_global_images_V12.5.15.0.RGGEUXM_20220826.0000.00_11.0_eea_b8c6b15c15.tgz

https://cdn-ota.azureedge.net/V12.5.15.0.RGGEUXM/begonia_eea_global_images_V12.5.15.0.RGGEUXM_20220826.0000.00_11.0_eea_b8c6b15c15.tgz

https://cdn-ota.azureedge.net/V13.0.8.0.SJHCNXM/atom_images_V13.0.8.0.SJHCNXM_20230630.0000.00_12.0_cn_acca549dfc.tgz

wget -c      --referer="https://miui.com/"    https://hugeota.d.miui.com/V12.5.6.0.RGGCNXM/begonia_images_V12.5.6.0.RGGCNXM_20220602.0000.00_11.0_cn_fbed701a77.tgz