关键词：保管链、封条、移交记录、委托书、鉴定意见书、瑕疵、补正
难度：入门
前置知识：取证流程与原则
一、概述
sha256sum 能证明"这串字节从 3 月 15 日到现在没变过"。它证明不了另一件事：这串字节是从哪个设备上、什么时间、由谁、以什么授权取下来的。
技术上这两件事毫无关系，法庭上却必须一起成立。对方律师只需要问一句："这份镜像在 3 月 5 日到 3 月 18 日之间在谁手上。"答不上来，前面所有哈希、所有解析、所有结论都可能被打回重来。
第五章那个 13 天空档，就是这个问题的真实版本。保管链补的就是这个缺口——表格、签字、封条、录像，全是纸面动作，它一点都不炫技，但这是唯一一个能回答"来源链条是否完整"的东西，技术手段一个都替代不了。
保管链不属于流程中的某一环，它横跨全程。从受理检材的第一分钟开始记录，到意见书盖章结束才闭合。对应关系说白了就是：受理对应采集环节的收尾，每次分析前后对应分析环节，出具文书对应报告环节。4.1 那条讲得更直白——受理时不计算源哈希，缺陷从此处开始就无法补救。后面的每一环都在错误的基础上叠加，越往后越说不清。
上游有三件事决定台账长什么样。取证流程与原则 决定你有多少个节点要记录；哈希与完整性校验 提供链上那个"技术兜底"性质的锚点；合规授权与法律边界 决定你有没有资格记录。没有授权，台账记得再规范也不解决问题。
下游有两件事。证据文件格式决定受理时拿到的是 DigiForensics.dd 还是 DigiForensics.E01，这两种情况下"受理哈希"算在哪个对象上完全不同；取证概念与分类给出文书类型与证据类别的对应关系。
落到纸面上，要处理的物件有确定的格式。保管链台账以证据编号为行，字段固定为时间（精确到分）、移交方、接收方、用途、哈希值、签名，只写日期不写时间是无效记录。
委托书 / 授权书由委托人签署，内容是委托事项、检材清单、权限范围、期限，它不是"授权使用"的凭据，两者法律定位不同（陷阱 2）。鉴定意见书 / 检验报告由鉴定人签署，核心是"这些数据说明什么"，必须写明局限性。
受理记录由检验方签署，固定的是"我收到了什么、状态如何"：检材状态、封条编号、哈希值、异常情况。封条与封装袋跨缝粘贴，横跨袋口与袋体，二次封装时原封条不得丢弃，它是过程证据。
H_recv.sha256 与 hash_chain.log 是受理哈希与分析前后哈希的追加日志，案例里让那 13 天空档变得可辩护的就是这个文件。udevadm info --query=property 的输出是受理时抓的设备型号与序列号，用于把台账里的"某某牌移动硬盘"落到唯一一台具体设备。
这些物件能回答的问题相当具体。一份保管链记录在质证中能不能站住，看的是要素是否齐全、链条是否闭合；三类文书该由谁签；发现封条破损时第一步该做什么；记录有瑕疵的情况下还能靠什么补救。
数据本身有没有被改过是哈希的活，保管链只负责保证那个哈希被记下来了；技术分析怎么做，保管链对镜像里有什么内容毫不关心；取证的合法性边界——授权要件缺失、非法获取的排除规则——属于合规授权与法律边界；鉴定意见书的正式格式各机构、各地区不同，保管链只讲结构要素，格式规定要查本机构的规范文本。
上手之前需要先理解三件事：哈希能证明什么（见哈希与完整性校验）、取证流程有哪几个阶段（见取证流程与原则）、以及只读接入为什么是纪律（见只读挂载与安全接入）。接过真实检材、也亲手做过哈希校验的人读到这里基本是在复述；这两样都还没做过的，先去做一遍再来读，因为 4.4 节讲的东西完全不是空话。
二、核心原理
2.1 保管链的定义与四要素
**保管链（Chain of Custody）**是指证据自固定之日至呈堂之止，为防止调换、遗失、毁损而采取的保管措施与记录。
| 要素 |
记录内容 |
常见缺失 |
| 谁（Who） |
交接双方姓名、单位、职务、签名 |
只写单位不写个人 |
| 何时（When） |
交接的准确日期与时间 |
只写日期不写时间 |
| 何地（Where） |
交接地点 |
完全不记录 |
| 做什么（What） |
本次操作性质（封存/移交/检验/归还） |
笼统写"移交" |
核心要求：保管链必须闭合且连续。任何一段无人负责的空白期，都是对方质疑"此期间数据可能被修改"的入口。
2.2 电子证据保管链的三个特殊点
| 特殊点 |
传统物证 |
电子证据 |
| 易被复制 |
物理上唯一 |
可无限复制，需说明副本关系 |
| 易被访问 |
拿走了就没了 |
封存的硬盘仍可被通电访问 |
| 可被验证 |
靠封条 |
靠哈希，可数学证明未变 |
正因如此，电子证据的保管链文档中必须包含哈希值，而且要与委托方、送检方、检验方各自掌握的记录对得上。
这就是"三段哈希"：
送检方（扣押时计算） H_send
↓
检验方（受理时计算） H_recv ← H_send == H_recv 是受理的前提
↓
检验方（检验后计算） H_after ← H_recv == H_after 是分析未改动的证明
2.3 三类文书的关系
初学者常把委托书、鉴定意见书、检验报告混为一谈。三者的法律定位完全不同：
| 文书 |
签署人 |
解决的问题 |
关键要素 |
| 委托书/授权书 |
委托人（通常是委托方或办案单位） |
"我请你做什么" |
委托事项、检材清单、权限范围、期限 |
| 受理/检验记录 |
检验方 |
"我收到了什么、状态如何" |
检材状态、封条编号、哈希值、异常情况 |
| 鉴定意见书 |
鉴定人 |
"这些数据说明什么" |
检材、检验过程、分析意见、局限性 |
三者的关系是：委托书授权 → 受理记录固定 → 意见书定论。缺任何一环，链条都不完整。
⚠️ 实务提醒：文书格式的具体要求因地区、机构、业务类型而异，以本机构规范、当地司法实践和最新法规要求为准。下文只给结构要素，不代替正式格式规定。
2.4 封装与封条
| 要点 |
做法 |
理由 |
| 封装材料 |
防拆封条 + 硬质封装袋/盒 |
便于观察是否被开启 |
| 封条信息 |
案件编号、检材名称、封装人、日期、签名 |
封条即保管链的物理载体 |
| 跨缝粘贴 |
封条横跨袋口与袋体 |
任何开启都会破坏封条 |
| 二次封装 |
分析后重新封装并记录 |
原封条不得丢弃，作为过程证据 |
| 影像留存 |
封装全过程拍照 |
封条破损争议时的旁证 |
封条破损或丢失怎么处理：先停下来，别拆。
1. 立即停止操作
2. 拍照记录破损状态
3. 通知委托方/办案人员
4. 在记录中如实写明发现时间与状态
5. 由双方共同拆封并签字确认
自行拆封后再"补一个记录"，质证时几乎无法自证。
2.5 保管链的常见断点类型
| 类型 |
表现 |
后果 |
| 时间断点 |
3 月 5 日到 3 月 18 日无记录 |
最严重——无从证明期间状态 |
| 主体断点 |
移交到某部门，未写具体人 |
无法定位责任人 |
| 操作未记录 |
期间做过分析但没写 |
对方可主张数据已被污染 |
| 哈希缺失 |
受理时未算哈希 |
无法证明镜像与原始检材一致 |
| 封装未记录 |
拆封装没签字 |
争议时无法证明拆封合法 |
三、操作步骤
步骤 1：受理检材时建立基线
这是整个保管链的起点，哈希必须在此计算：
# 1) 记录检材标识
lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE
# 2) 检查封装与封条（拍照存档）
# 3) 记录开机状态（指示灯、屏幕）
# 4) 计算并记录哈希 —— 若为已封存的镜像文件
sha256sum DigiForensics.dd | tee /case/H_recv.sha256
md5sum DigiForensics.dd | tee -a /case/H_recv.sha256
# 5) 若为原始介质（尚未镜像），先记录设备信息，镜像后按板块 2 流程走
把哈希值写进受理记录，并请委托方当场确认签字。
步骤 2：建立保管链台账
保管链记录（示例格式）
案件编号：2024-DG-001
检材编号：DG-001-01
检材名称：笔记本电脑（Laptop）
检材特征：型号 XXX，序列号 XXXXXXXXX，容量 512GB
序号 | 日期时间 | 交出方 | 接收方 | 地点 | 事由 | 封条号 | 签名
1 | 03-15 09:20 | 张某(委托方) | 李某(检验方) | 委托方办公室 | 送检 | A-001 | ...
2 | 03-15 14:00 | 李某 | 李某 | 检验方实验室 | 封存 | A-001 | ...
3 | 03-16 10:30 | 李某 | 王某(复核) | 检验方实验室 | 检验 | A-002 | ...
4 | 03-25 16:00 | 王某 | 张某(委托方) | 检验方实验室 | 归还 | A-003 | ...
💡 实用建议：台账用电子表格维护，每次操作后立即录入。事后补记的时间经常与实际不符，反而制造矛盾。
步骤 3：封装
封装流程
1 核对检材与台账记录一致
2 装入封装袋，排出空气
3 封条横跨袋口，注明案件编号、检材号、封装人、日期
4 封装人签名
5 拍照（正反面、封条特写）
6 台账登记本次封装
步骤 4：每次分析前后记录哈希
# 分析前
sha256sum DigiForensics.dd >> /case/hash_chain.log
echo "分析前: $(date)" >> /case/hash_chain.log
# ... 执行分析 ...
# 分析后
sha256sum DigiForensics.dd >> /case/hash_chain.log
echo "分析后: $(date)" >> /case/hash_chain.log
步骤 5：发现封条异常时的处置
发现封条破损
↓
立即停止一切操作，不要通电，不要拆封
↓
拍照：破损位置、整体状态、当前摆放位置
↓
通知委托方/办案人员到场
↓
双方共同在场拆封，各执一份记录
↓
在保管链台账中如实写明：
发现时间、发现人、破损描述、处置方式、在场人员
↓
重新封装（新封条号），旧封条留存
步骤 6：出具文书
按第三节的三类文书分别准备。鉴定意见书的关键是局限性章节必须写：
局限性声明（示例）
1. 本次检验仅针对检材 DG-001-01 镜像文件进行，未接触原始存储介质。
2. 检材到所时封装完好，海绵 3 月 15 日 09:20 送达。
3. 因检材为关机状态，未能提取内存中的易失数据。
4. 因 X 部件损坏，偏移 0x1A2F00000 附近约 0.5GB 数据无法读取。
5. 本意见仅基于所提取数据作出，对未提取部分不作判断。
四、常见陷阱
4.1 受理环节（缺陷从这里开始就无法补救）
受理时不计算源哈希 ★
现象：设备到手直接开始采集，直到写报告时才对着采集镜像算一次 SHA-256，台账上只有镜像的哈希。
为什么会误判：受理哈希是保管链的起点。
没有它，就无法证明"采集出来的镜像忠实反映了委托方交付的那块原始介质"。中间这段时间里设备是否被替换、是否被通电、是否被改动，完全没有客观记录。
取证人员往往认为"采集时的哈希已经覆盖了"。可采集工具算的是它读到的字节流；读到的到底是不是原始介质本身，得靠受理哈希来锚定。
误判代价：这是保管链上最大的、也最难事后补救的漏洞。
质证时对方只需一问"你如何证明镜像对应的是我方交付的那台设备"，整条链就断了。而且它是证据性的缺陷——不是记录格式不规范，是缺少关键事实。
正确做法：先哈希、再通电、再采集，顺序不可颠倒。
受理时即对交付的原始介质计算哈希，并当场录像或双人在场见证。原始介质因为通电而可能被改写（SSD 的磨损均衡、写缓存、TRIM），通电前不哈希，之后就再也拿不到原始状态了。
# 受理环节：先算哈希（此时设备尚未通电，dd 只读不写）
sha256sum /dev/sdX | tee 受理哈希.txt
# 记录设备型号、序列号、接口、封条编号、交付人
把委托书当作授权使用
现象：拿到委托书，上面写着"委托贵机构对某设备进行取证"，于是开始了解封、挂载、恢复文件。
为什么会误判：委托书表达的是"请你做事"，不必然包含"你可以处置我的数据"。
委托关系与处理权限是两个独立问题。很多委托书里根本没有写明是否允许解密数据、是否允许登录对方账号、是否允许把数据带出原环境。取证人员默认"收了委托书就等于什么都能做"。
误判代价：可能构成违法或违约。
擅自解密他人设备、越权访问他人账户，取证结论不但会被排除，还可能引发独立的责任后果。
正确做法：权限范围必须在委托书中逐项写明。至少明确四点：① 是否允许解密与挂载；② 是否允许访问云账户或第三方服务；③ 数据可否带离现场或出境；④ 哪些数据不得处理。
授权范围模糊时，先问再动手，并把沟通记录附入案卷。
4.2 台账记录
事后补记台账
现象：交接时没来得及填台账，事后回忆补上，日期写了当天，但时间填的是"大概上午"。
为什么会误判：补记的时间与实际操作时间不符，这在质证中是明显破绽。
台账的核心价值不是"有个记录"，而是"记录的时刻是真实的"。事后补记破坏的正是这一点。填写台账时人是匆忙的，事后补记人是回忆的，两者性质完全不同。
误判代价：整个台账的真实性被质疑。
对方一旦指出"这张台账是补的"，前面所有真实记录的可信度都会一起下降。一处污染拖垮全表。
正确做法：当场记录，当场签字。台账设计成可以快速勾选的形式（预印选项 + 空格填时间），降低现场填写成本。
实在来不及的，先记下关键要素——时间、人、动作——再补格式，并在补记处注明"补记"及原因。
只写日期不写时间
现象：台账上写"2026-03-15 接收"，没有具体时刻。
为什么会误判：跨夜或多人交接的场景下，只有日期无法确定顺序。
"15 日接收、15 日采集、15 日移交
