EAP-扩展认证协议

发表评论

Extensible Authentication Protocol
EAP是一个认证框架，EAP本身不是认证协议，它自己不支持认证功能，它是为了承载多种认证协议而生的
EAP 提供一些公共的功能，并且允许协商所希望的认证机制。这些机制被叫做 EAP 方法，现在大约有 40 种不同的方法：
EAP-MD5—MD5Hash函数容易受到字典攻击，它被使用在不支持动态WEP的EAP中
….
EAP-SIM
EAP-AKA
EAP-AKA`

主要关注 EAP-SIM/AKA

EAP-SIM/AKA 使用从移动网络中获得的鉴权三元组（EAP-SIM认证）或者五元组（EAP-AKA），得到认证需要MAC值，以及加密用的密钥
RFC 4186
RFC 4187 EAP-AKA Authentication

EAP-SIM用于GSM网络，只支持单向认证，即支持网络认证UE，但是不支持UE认证网络。
EAP-AKA是EAP-SIM的升级版本，用于3G网络中的用户认证，支持双向认证。
EAP-AKA’是一种新的EAP认证方法，在RFC5448中定义
Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement

1. 终端，发送 UMTS AKA 认证请求给USIM卡

2. USIM对AUTN 进行验证， 从而来认证网络
2.1 AUTN 不正确， 终端将拒绝这次认证；
如果SQN 失效， 将重新发起 SQN同步
2.2 如果AUTH正确， USIM将计算出 RES, IK, CK ， 返回给终端

3. 终端 从 CK 和 IK 导出所需新的密钥材料
4. 解密新的临时标识符并保存以备下次使用验证
5. 发送 含有 RES 的 EAP Response/AKA-challenge 给认证服务器

XKEY = SHA-1 (Identity | CK | IK)

FIPS 186-2 伪随机数生成器

https://www.rfc-editor.org/rfc/rfc4187.html

In the 3rd generation mobile networks, AKA is used for both radio network authentication and IP multimedia service authentication purposes.

Different user identities and formats are used for these;
the radio network uses the International Mobile Subscriber Identifier (IMSI), whereas the IP multimedia service uses the Network Access Identifier (NAI)

1. 终端向 认证服务器 发送 EAP-Request/Identity 来报告自己的身份。
2. 服务器返回 EAP-Response/Identity (包括用户的NAI)
3. 服务器运行 AKA算法，生成rand和autn
4. 服务器，下发 EAP-Request/AKA-Challenge ，里面包含
AT_RAND, AT_AUTN, AT_MAC
5. 客户端， 运行AKA算法， 验证 AUTN和MAC, 并生成RES和 session key
6. 客户端发送 EAP-Response/AKA-Challenge (包含AT_RES, AT_MAC)给服务器
7. 服务器验证RES和MAC, 发现是正确， 双方认证成功

——————–
客户端触发：
设备启动（或者设备没有重启，但是换了张 SIM卡), 并且该用户没有可用的配置时，
设备将发送一个初始http请求
—————–
永久用户名的格式

‘0’ IMSI
也就说说用户名的第一个字节是 0x30, 然后就是ascii编码的IMSI

———————–
EAP的包格式
第1个字节： Code
可能的值为
1 Request
2 Response
3 Success
4 Failure
其他值，忽略

第2个字节： Identifier
用来匹配 Request和Respone的，不然乱套了，不知道到谁是谁的响应

第3-4字节： Length
整个包的长度，包括 Code, Identifier, Length , Data

Integrity protection (AT_MAC) is based on a keyed message authentication code.
Confidentiality (AT_ENCR_DATA and AT_IV) is based on a block cipher.

The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value.
(The HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by truncating the output to 16 bytes. Hence, the length of the MAC is 16 bytes.)

The derivation of the authentication key (K_aut) used in the calculation of the MAC

On EAP-AKA full authentication, a Master Key (MK) is derived from the underlying AKA values (CK and IK keys), and the identity, as follows.

MK = SHA1(Identity|IK|CK)

The Master Key is fed into a Pseudo-Random number Function (PRF),
which generates separate Transient EAP Keys (TEKs) for protecting
EAP-AKA packets, as well as a Master Session Key (MSK) for link layer
security and an Extended Master Session Key (EMSK) for other
purposes. On fast re-authentication, the same TEKs MUST be used for
protecting EAP packets, but a new MSK and a new EMSK MUST be derived
from the original MK and from new values exchanged in the fast
re-authentication.

EAP-AKA requires two TEKs for its own purposes: the authentication
key K_aut, to be used with the AT_MAC attribute, and the encryption
key K_encr, to be used with the AT_ENCR_DATA attribute. The same
K_aut and K_encr keys are used in full authentication and subsequent
fast re-authentications.

Key derivation is based on the random number generation specified in
NIST Federal Information Processing Standards (FIPS) Publication
186-2 [PRF]. The pseudo-random number generator is specified in the
change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As
specified in the change notice (page 74), when Algorithm 1 is used as
a general-purpose pseudo-random number generator, the “mod q” term in
step 3.3 is omitted. The function G used in the algorithm is
constructed via Secure Hash Standard as specified in Appendix 3.3 of
the standard. It should be noted that the function G is very similar
to SHA-1, but the message padding is different. Please refer to
[PRF] for full details. For convenience, the random number algorithm
with the correct modification is cited in Annex A.

160-bit XKEY and XVAL values are used, so b = 160. On each full
authentication, the Master Key is used as the initial secret seed-key
XKEY. The optional user input values (XSEED_j) in step 3.1 are set
to zero.

On full authentication, the resulting 320-bit random numbers x_0,
x_1, …, x_m-1 are concatenated and partitioned into suitable-sized
chunks and used as keys in the following order: K_encr (128 bits),
K_aut (128 bits), Master Session Key (64 bytes), Extended Master
Session Key (64 bytes).

On fast re-authentication, the same pseudo-random number generator
can be used to generate a new Master Session Key and a new Extended
Master Session Key. The seed value XKEY’ is calculated as follows:

XKEY’ = SHA1(Identity|counter|NONCE_S| MK)

In the formula above, the Identity denotes the fast re-authentication
identity, without any terminating null characters, from the
AT_IDENTITY attribute of the EAP-Response/AKA-Identity packet, or, if
EAP-Response/AKA-Identity was not used on fast re-authentication, it
denotes the identity string from the EAP-Response/Identity packet.
The counter denotes the counter value from the AT_COUNTER attribute
used in the EAP-Response/AKA-Reauthentication packet. The counter is
used in network byte order. NONCE_S denotes the 16-byte random
NONCE_S value from the AT_NONCE_S attribute used in the
EAP-Request/AKA-Reauthentication packet. The MK is the Master Key
derived on the preceding full authentication.

On fast re-authentication, the pseudo-random number generator is run
with the new seed value XKEY’, and the resulting 320-bit random
numbers x_0, x_1, …, x_m-1 are concatenated and partitioned into
64-byte chunks and used as the new 64-byte Master Session Key and the
new 64-byte Extended Master Session Key. Note that because K_encr
and K_aut are not derived on fast re-authentication, the Master
Session Key and the Extended Master Session key are obtained from the
beginning of the key stream x_0, x_1, ….

The first 32 bytes of the MSK can be used as the Pairwise Master Key
(PMK) for IEEE 802.11i.

When the RADIUS attributes specified in [RFC2548] are used to
transport keying material, then the first 32 bytes of the MSK
correspond to MS-MPPE-RECV-KEY and the second 32 bytes to
MS-MPPE-SEND-KEY. In this case, only 64 bytes of keying material
(the MSK) are used.

Watch

发表评论

/System/Library/PrivateFrameworks/CellularPlanManager.framework/CellularPlanManager
/System/Library/PrivateFrameworks/CellularPlanManager.framework/Contents/MacOS/CellularPlanManager
/System/Library/PrivateFrameworks/CellularBridgeUI.framework/CellularBridgeUI

—————
共享缓存机制

在iOS系统中，每个程序依赖的动态库都需要通过dyld（位于/usr/lib/dyld）一个一个加载到内存，然而，很多系统库几乎是每个程序都会用到的，如果在每个程序运行的时候都重复的去加载一次，势必造成运行缓慢，为了优化启动速度和提高程序性能，共享缓存机制就应运而生。所有默认的动态链接库被合并成一个大的缓存文件，放到/System/Library/Caches/com.apple.dyld/目录下，按不同的架构保存分别保存着
dyld_shared_cache_arm64 到 dyld_shared_cache_arm64.5

想要分析某个系统库，就需要从dyld_shared_cache里先将的原始二进制文件提取出来
———–
-[CTCellularPlanManager remotePlanLaunchInfoForEid:completion:]
-[CTCellularPlanManager didCancelRemotePlan]
-[CTCellularPlanManager pendingReleaseRemotePlan]
-[CTCellularPlanManager subscriptionDetailsForCompletion:]
-[CTCellularPlanManager didPurchaseRemotePlanForEid:imei:meid:iccid:alternateSmdpFqdn:completion:]
-[CTCellularPlanManager eraseAllRemotePlansWithCompletion:]
————————————————————————
-[CTCellularPlanItem initWithCellularPlan:uuid:iccid:name:type:phoneNumber:label:isLocalTransferToeSIMSupported:isTransferred:transferredStatus:transferredToDeviceDisplayName:]

-[CTCellularPlanItem initWithCellularPlan:uuid:type:phoneNumber:label:transferredStatus:transferredToDeviceDisplayName:]

-[CTCellularPlanItem initWithIccid:uuid:name:phoneNumber:label:isLocalTransferToeSIMSupported:isTransferred:transferredStatus:transferredToDeviceDisplayName:]

-[CTCellularPlanItem isLocalTransferToeSIMSupported]
-[CTCellularPlanItem setIsLocalTransferToeSIMSupported:]
————————-
-[CTCellularPlanManager setIMEIPrefix:]
-[CTCellularPlanManager getESimServerURL:]
-[CTCellularPlanManager setESimServerURL:]
———————-
int -[COSAboutDataSource getIMEI:]
void -[COSAboutDataSource getCarrierInfo:]
int -[COSAboutDataSource getSerialNumber:]
-(int)getDeviceModel:(int)
————————-
-[COSEIDDetailsController EIDString:]
———————-
+[NPHSharedUtilities isActiveWatchChinaRegionCellular]:
int -[NPHCellularBridgeUIManager startRemoteProvisioning]

-[CTCellularPlanManager addNewPlanWithUserInWebsheetWithUserConsent:completion:]
-[CTCellularPlanManager didPurchasePlanForCsn:iccid:profileServer:state:]
-[CTCellularPlanManager remotePlanLaunchInfoForEid:completion:]
CellularPlanManager这个文件
-[CTCellularPlanManager loadPlansWithUrl:postData:completion:] 联通应该是用这样

-[CTCellularPlanManager setSkipEligibilityCheck:] 跳过条件检查
-[CTCellularPlanManager getSkipEligibilityCheck:]
-[CTCellularPlanManager openInternalUrlId:]
-[CTCellularPlanManager setESimServerURL:]
-[CTCellularPlanManager getESimServerURL:]
-[CTCellularPlanManager getRemoteInfo:]
-[CTCellularPlanManager getIMEIPrefix:]
-[CTCellularPlanManager addNewRemotePlanWithAddress:matchingId:oid:confirmationCode:isPairing:withCSN:withContext:userConsent:completion:]
CTCellularPlanRequest
initWithUrl:(int)arg2 httpMethod:(int)arg3 httpHeaders:(int)arg4 httpBody

-[CTCellularPlanRequest initPostWithUrl:]
initJsonPostWithUrl
initJsonPostWithUrl
-[CTCellularPlanRequest initGetWithUrl:]
loadPlansWithUrl:(int)arg2 postData:(int)arg3 completion

+[CTCellularPlanRequest(Factory) loadPlansRequestWithUrl:postData:]

esim操作apdu实例解析

发表评论

ETSI TS 102 221 V17.4.0 (2023-02)
TERMINAL CAPABILITY
————————-
GPC_SPE_007

Global Platform Card Specification – Public Release v2.3.1

The STORE DATA command message shall be coded according to the following table.

P1= 91
Last block
命令的数据域是 BER-TLV 格式

DER编码
GetEID== Tag ‘BF3E’ （GetEuiccDataRequest）
The data field SHALL indicate EID data object ‘5C 01 5A’ (tag ‘5A’ identifies the EID).
tag ‘5C’

响应 Tag ‘BF3E’
tag ‘5A’

============================
ProfileInfoListRequest ‘BF2D’
EnableProfileRequest Tag ‘BF31’
DisableProfileRequest ‘BF32’
DeleteProfileRequest ‘BF33’

GetEuiccDataResponse ‘BF3E’
————————————————–
Send Terminal Capabilities

80 aa 00 00 0a a9088100820101830107

回应

9000

Open Logical Channel and Select ISD-R

00a4040010 a0000005591010ffffffff8900000100

响应

6f81818410a0000005591010ffffffff8900000100a566735706072a864886fc6b01600b06092a864886fc6b020202630906072a864886fc6b03640b06092a864886fc6b048000650d060b2a864886fc6b05040200006618060a2b060104012a026e0103060a5354333347314d3201019f6e060077831801019f6501ffe0058203020200

9000

get status
80f2000c00

list profile
81 E2 91 00 03 BF2D00

获取EID
81 e2 91 00 06 bf3e 03 5c 01 5a

getEuiccConfiguredAddresses
81 E2 91 00 03 BF3C00

bf 3c
32
80 1f 6573696d2e7968647a642e6368696e616d6f62696c652e636f6d3a38303031 (esim.yhdzd.chinamobile.com:8001)
81 0f 6c70612e64732e67736d612e636f6d (lpa.ds.gsma.com)
9000

Enable Profile
81 E2 91 00 1A BF31 17 A0 12 4F 10 A0000005591010FFFFFFFF8900001100 8101FF

eSim Profile

发表评论

eSim Profile含有：

1个MNO-SD (卡上的运营商代表,含有OTA密钥，提供安全的OTA通道)

SSD（补充安全域)和CASD

Applets

应用（比如NFC应用)

NAAs (SIM核心元素，Network Access Application== Application residing in a Profile providing authorisation to access
a network）

文件系统的其它元素

Profile metadata(包括Profile Policy Rules)

保护与传输
Unprotected Profile Package (UPP): 未保护的Profile包，原始的 TLV 序列
Protected Profile Package (PPP): 以BSP负载TLV形式 组成的 分段保护的包
Bound Profile Package (BPP):
Segmented Bound Profile Package (SBPP): 可以用STORE DATA命令存入UICC的形式

Local Discovery Service
Local Profile Download
Local User Interface

SM-DS 的作用是提供一种机制， 允许 SM-DP+ 去通知 希望与之通信的任何设备中 的 LDS 。
SM-DS 到 LDS 通信的目的，是告诉它有一个待处理的事件。
SM-DP+ 会为 目标设备的LDS 发送一条到 SM-DS 的 事件注册消息。

在简单部署中，仅在 eUICC 上配置 Root SM-DS。 Root SM-DS地址是唯一的，填写在eUICC中。

目标设备中的 LDS 使用同样的逻辑位置 去 轮询 Root SM-DS 。
当Root SM-DS 具有目标设备的事件 ID 时, 它将使用 SM-DP+ 地址，对这次轮询进行响应;
如果没有事件 ID，则 回 一个空响应。

在级联SM-DSs的部署中， SM-DP+ 将发送一条事件注册消息 给 一个替代的SM-DS, 这个SM-DS可能没有被配置成Root SM-DS.
但是这个替代的SM-DS会将事件注册消息 级联地发给Root SM-DS.

目标设备中的LDS， 轮询Root SM-DS时，就会收到 替代的SM-DS地址。 然后LDS将向 替代的SM-DS发出 事件请求， 对应的SM-DS会响应
SM-DP+的地址。

Root SM-DS服务器由GSMA管理， 只通过同一个地址访问，后面有很多台物理服务器担当服务。

esim概念解析

发表评论

Embedded UICC Controlling Authority Security Domain (ECASD) 负责安全存储支持 eUICC 上所需安全域所需的凭证。

一个 eUICC 上应该只有一个 ECASD。 ECASD 应在 eUICC 制造期间由 EUM （卡商) 安装和个性化，如 GlobalPlatform 卡规范中所述。

ECASD 应包含以下内容：

1. 用于创建签名的 eUICC 私钥      eUICC’s Private Key(s) (SK.EUICC.SIG) 。
2. eUICC认证的证书 (CERT.EUICC.SIG), 此证书含有eUICC的公钥 (PK.EUICC.SIG）。
3. 用于验证 SM-DP+ 和 SM-DS 证书的证书颁发者 (CI) 根证书的公钥 （PK.CI.SIG） 。
4. eUICC 制造商 (EUM) 用于 更新 密钥/证书的密钥集 （(CERT.EUM.SIG)。

      可以更新：

         1）eUICC’s Private Key(s) 和 Certificate(s)

         2)  EUM Certificate(s)

        3)  eSIM CA RootCA public key(s)

       4)  添加 新的 new eUICC Private Key(s), eUICC Certificate(s), EUM Certificate(s)

      5） 

此外，ECASD 应提供在密钥建立和 eUICC 身份验证期间使用的安全功能。

ISD-R 负责创建新的 ISD-P 和 管理 所有 ISD-P 的生命周期。

ISD-P 是用于托管 配置文件(Profile)的安全容器（安全域）。 ISD-P 与配置文件包解释器(用于对接收到的绑定配置文件包,进行解码/解释) 协作, 来完成配置文件下载和安装.

ISD-P是 SM-DP+ 在卡上的代表。

MNO-SD
MNO-SD 是发布配置文件的运营商的卡上代表。 它包含运营商的无线 (OTA) 密钥并提供安全的 OTA 通道。

Profile Policy Enabler
eUICC 操作系统 (OS) 的一个服务，提供配置文件策略规则验证和执行。

Telecom Framework
Telecom Framework 是一种操作系统服务，它为 ISD-P 中托管的 NAA（SIM卡应用) 提供标准化的网络认证算法。 此外，它还提供了使用必要参数配置算法的能力。

Profile Package 解释器是一个 eUICC 操作系统服务，它 将 Profile Package Data 转换为 目标 eUICC 的特定内部格式 的Profile.

LPA 服务

提供 对 （LPA功能要求中定义的）的服务和数据的访问，包括：
1. root SM-DS地址。
2. 可选存储的默认 SM-DP+ 地址。
3. 便于接收从 LPA 传输的绑定配置文件包。(从LPAd传到ISD-P)
4. 提供有关已安装配置文件及其配置文件元数据的信息。
5. 提供本地配置文件管理
6. 支持远程配置文件管理操作
7. 为LPA 提供与SM-DS 进行身份验证和交互的功能。
8. 确保对 EID 的访问仅限于 LPA。

dart-在model classes里序列化JSON

发表评论

user.dart

class User {
  final String name;
  final String email;

  User(this.name, this.email);

  User.fromJson(Map<String, dynamic> json)
      : name = json['name'],
        email = json['email'];

  Map<string, dynamic> toJson() => {
        'name': name,
        'email': email,
      };
}

hello.dart

import 'dart:convert';
import 'user.dart';

String jsonString = '''
{
  "name": "John Smith",
  "email": "john@example.com"
}
''';


void main() {
    Map<String, dynamic> userMap = jsonDecode(jsonString);

    var user = User.fromJson(userMap);

    print('Howdy, ${user.name}!');
    print('We sent the verification link to ${user.email}.');

    String json = jsonEncode(user);
    print(json);
}

被调用的代码根本不需要担心序列化 JSON 数据的问题。然而，你仍然需要模型类。你当然会希望序列化数据在一个生产环境的应用里能奏效。在实践中，User.fromJson() 和 User.toJson() 方法都需要单元测试以便验证正确的行为。

使用 dart:convert 手动序列化 JSON 数据

发表评论

将下列内容保存为 hello.dart

import 'dart:convert';


String jsonString = '''
{
  "name": "John Smith",
  "email": "john@example.com"
}
''';



void main() {

    Map user = jsonDecode(jsonString);

    print('Howdy, ${user['name']}!');
    print('We sent the verification link to ${user['email']}.');
}

运行
dart hello.dart

各运营商的VoWiFI服务

发表评论

统一由3gpp来管理的

https://www.freecheckdomain.com/cn/dnsCheck.html
https://dnschecker.org/
来检测

中国联通，此域名不存在
epdg.epc.mnc001.mcc460.pub.3gppnetwork.org


马来 U Mobile
epdg.epc.mnc018.mcc502.pub.3gppnetwork.org
123.136.110.180
123.136.100.132


泰国 AIS
epdg.epc.mnc003.mcc520.pub.3gppnetwork.org
119.31.121.14
119.31.123.26

MCC 520 泰国 Thailand
MNC 01 AIS
03 AIS
15 AIS
23 AIS
—————
MCC 502 马来西亚 Malaysia
01 Telekom
11 MTX Utara
12 Maxis
13 TM Touch
16 DIGI
17 Maxis
18 U Mobile
—————

epdg.epc.mnc260.mcc310.pub.3gppnetwork.org CNAME epdg.epc.geo.mnc260.mcc310.pub.3gppnetwork.org
epdg.epc.geo.mnc260.mcc310.pub.3gppnetwork.org 208.54.36.3
208.54.40.3
208.54.148.227
208.54.87.3
208.54.2.67
208.54.39.35 （可用)

epdg.epc.mnc260.mcc310.pub.3gppnetwork.org epdg.epc.geo.mnc260.mcc310.pub.3gppnetwork.org
208.54.2.67 (可用)
————-

UDP port 500或4500 是 Internet Security Association and Key Management Protocol (ISAKMP）

UDP PORT 4500是 UDP-encapsulated ESP and IKE
——————–
在OpenWRT的 /etc/config/firewall里有放行的配置

config rule                 
        option name 'Allow-IPSec-ESP'
        option src 'wan'       
        option dest 'lan'
        option proto 'esp'   
        option target 'ACCEPT'   

config rule                   
        option name 'Allow-ISAKMP'
        option src 'wan'              
        option dest 'lan'    
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

IPSEC建立分为三个阶段：phase1(建立IKE SA)、phase1.5(xauth，可选)、phase2（建立最终SA并协商SA参数）

IPSEC建立好之后，用ESP协议封装报文。ESP是等同于UDP\TCP的协议，IP协议号是50（因此ESP并不是UDP的上层协议，而是跟UDP\TCP平行协议）

当IKE在阶段一进行NAT监测时候，发现网络中存在NAT，IKE会把端口从500改到4500，后续的ESP流量前面加一个UDP的头，端口4500

在vowifi场景下，NAT是肯定存在的，所以500端口只有第一个请求才会用到，后面都是4500,（而且4500这个 UDP-encapsulated ESP and IKE是不可以配置和更改的，是RFC规定死的 ）。