클라우드 스토리지 내부 API 트래픽 분석을 통한 파일 활동 로그 식별 연구
각 클라우드 스토리지 서비스 제공자별로 사용자의 활동이 어느정도 수준으로 어떤 부분이 기록되는지를 파악함
Box 클라우드 스토리지 서비스에서는 서비스 내부적으로 어떤 툴을 사용하였는지도 기록함
내부 API 트래픽을 분석하여 파일 활동 로그 기반 10가지 주요 사용자 행위 식별 방법론 제안
각 서비스 제공자별 공통 필드가 무엇이며, 각 서비스별 특징적인 필드가 무엇인지를 확보
비공개 API를 대상으로 진행한 연구이기 때문에 API 구조 변경 가능성 있음, 법적 근거로 사용되기 위해서는 제대로 된 법적 절차를 밟아야 함
macOS 환경에서의 카카오톡 데이터베이스 복호화
macos용 카카오톡 데이터베이스 복호화 방안 연구의 후속 연구
MacOS용 카카오톡 바이너리는 ARM, X86이 섞여있는 형태였음
카카오톡 데이터베이스 파일명, 데이터베이스 키 생성은 Device UUID와 SHA를 사용하여 생성됨
유저, 단체채팅 디렉터리 이름은 이름을 역순으로 뒤집는 등의 난독화?를 거쳐 생성됨
위 키 생성 원리를 역순으로 진행하면 카카오톡 채팅방에 있던 이미지 등을 복호화 하는게 가능함
코드가 현실이 될 때: LLM 기반 로봇 제어 코드의 안정성 위험 분석 및 대응 가능성 연구
코드 수준의 오류는 로봇 동작으로 반영됨
LLM 수준의 오류도 동작으로 반영, 즉 현실로 이어짐
LLM 생성 제어 코드를 ROS2 환경에서 실제 실행해봄
생성한 코드를 별도의 수정 없이 즉시 ROS2 환경에 적용한 것이 핵심
validator 기반 mitigation 기법, LLM이 생성한 코드를 validator를 통해 안정성 검사 수행, 규칙 기반으로 동작함
4개의 주요 목표, 20개의 환경으로 총 80개의 시나리오를 사용
Failure는 충돌, 비정상 동작, 목표 미도달, 실행 실패로 정의함

코드의 구조적 문제로 인한 실행 실패는 개선하지 못한 것을 알 수 있음
과도한 전진, 공격적인 이동이 줄어들어 더 안정적인 제어가 이루어진 결과로 해석이 가능함
굳이 LLM 코드를 바로 로봇에 적용시킬 때 저런 위험 요소를 줄인다기 보다는 QA 자체를 더 강화하는게 결과적으로는 더 효율적이지 않을까?
validator 기반 mitigation 기법에서 어떻게 위험한 코드를 인식하는지?
C-to-Rust 변환 시 발생하는 원시 포인터 문제와 해결 방안 연구 동향
규칙기반, 정적 분석 기반, LLM 기반
정적 분석 기반은 빠른 처리가 장점
LLM 기반의 경우 C2SafeRust가 있음
정적 분석 기반으로 변환된 코드를 LLM이 실행을 통해 원본 코드와 동일하게 작동하는지를 검증한다.
Sactor 또한 LLM 기반, C 코드를 보존하는 비 Rust 코드로 변환, 이후 Crown 분석 후 LLM으로 Rust로 변환함
Deepseek R1이 가장 좋은 결과를 냄

한계 : 외부 C 라이브러리 의존성, 복잡한 데이터 구조, 형식적 정확성 보장 부재
컴파일 통과 후 종단간 암호화 테스트?를 거쳐도 모든 경우에 원본과 동일한 동작을 한다고 보장할 수 없음
대규모 언어모델의 보안 위협 및 대응 기법 동향: Prompt Injection과 Jailbreak 공격 중심
기존 안전 정책만으로는 LLM을 대상으로 하는 공격을 막기 힘듦
모델이 어떤 지시를 신뢰하고 따라야 하는지에 대한 문제이다.
실제 서비스 환경에서는 여러가지 tool과 결합되어 나타날 수 있음
LLM 보안은 프롬프트 문제가 아닌 LLM과 연관된 시스템 전반에 대한 문제
LLM 공격에 대한 위협으로는 프롬프트 인젝션, 탈옥 등이 있음
프롬프트 인젝션 : 시스템 프롬프트나 외부 입력에 악의적인 내용을 추가하여 원래 기능과 다른 기능을 하게 하는 것, RAG이나 에이전틱 환경에서 더 위험성이 커진다.
Direct 프롬프트 인젝션은 사용자가 직접, Indirect는 웹페이지 등에 악의적인 프롬프트를 숨기는 것, RAG을 대상으로?
실제 서비스에서는 Indirect Prompt injection이 더 위험할 수 있음
Jailbreak는 학습, 정렬 과정에서 갖게 된 안정 정책을 우회하는 것을 목적으로 함. 이전까지는 사용자가 직접 Jailbreak prompt를 작성하는 형태였지만 현재는 멀티턴, 자동 최적화, 이미지 기반 공격 등 여러가지 공격 수법이 사용되고 있음.
최근 공격은 사용자가 직접 프롬프트를 작성하는 것이 아닌 에이전트, 자동화를 적극적으로 사용하는 추세
멀티턴 에이전트 환경을 고려하여 단순한 프롬프트 방어가 아닌 LLM 시스템 전반에 대한 방어가 중요해짐
Agentic AI 보안 취약점 대응을 위한 Zero Trust 기반 아키텍처 설계

기존 보안 모델로는 Agentic AI에 충분한 수준의 보안을 제공할 수 없음
공통적인 취약점으로 내부 구성 요소를 신뢰한다는 것이 있음, 이를 해결하기 위해 제로 트러스트를 도입할 수 있다.
제로 트러스트의 필요성? 내부 에이전트에 대한 지속적인 검증이 필요, 내부 에이전트가 공격자에게 탈취당하거나, 오염된 경우 신뢰하지 않아야 함
에이전트가 작동 과정에서 생성한 코드가 안전한지를 검사해야 함
지식 그래프 기반 시각 표현 보정을 통한 LVLM 복원 연구
Prefix Tuning 기반 출력 행동 LLM 핑거프린팅 기법을 이용한 무결성 검증
필요성 : LLM은 제 3자 운용 과정에서 원본 LLM에 추가 파인튜닝, 압축, 교체, 백도어 삽입 등의 변조가 발생할 수 있음
prefix tuning이란 대규모 언어모델의 모든 파라미터를 고정한 후 입력 앞에 학습가능한 prefix embedding을 추가하여 모델의 동작을 조정하는 기법
모델 가중치에 직접적으로 접근이 불가능한 상태에서 유용하다?
인간과 AI의 시각적 인지 차이를 활용한 적대적 피싱 로고 생성 기법
이 발표는 방어가 아닌 공격 관점, AI 모델이 피싱 사이트에서 로고가 일반적인 회사의 로고와 비슷하다고 판단할 경우 피싱 사이트로 분류하는데 사람의 입장에서는 충분히 원본 로고와 유사하게 보이지만 AI 입장에서는 피싱 사이트라고 분류하지 않을 수준으로 다르게 보이는 로고를 생성하는 방법을 제시함
에이전틱 AI 환경에서의 데이터 과다 수집 위협 분석
과도한 정보 노출로, 민감하지 않은 정보들이 민감 정보로 합성될 가능성이 있음, 필요한 필드만을 출력함으로써 이와 같은 문제를 예방한다.
Atomic Read를 통해 최소 단위 데이터를 반환한다.
하지만 대부분의 MCP의 경우 재사용성과 개발 편의성을 위해 정보의 최소화 원칙을 지키지 못하고 있다. 단 한번의 도구 호출만으로 민감한 정보 노출이 가능.
현실적으로 Atomic Read로 전부 전환하는건 불가능함, 관리 복잡도 증가, 도구 선택 오류 가능성, 레거시 지원 등의 문제가 있음
기존의 데이터 유출 방지 솔루션의 범위를 MCP 도구 호출에서도 적용해야 한다. 단순 키워드 필터링이 아닌 MCP가 사용자의 프롬프트를 이해하는 수준
이미지 생성 모델의 개념 억제 연구 동향과 향후 연구 방향: 제어 장벽 함수를 중심으로
제어 이론 : 동역학계에서 시스템을 원하는 방향으로 작동하는 것
대규모 환경에서의 Tor 트래픽 상관 분석을 위한 근사 최근접 이웃 탐색 기반 기법
Evaluation of eBPF-Based Kernel-Level Data collection for controller area network intrusion detection systems
LLM 기반 단일 에이전트와 다중 에이전트 시스템의 보안 양상 비교
단일 에이전트에서는 입력, 권한 경계를 보호
다중 에이전트에서는 관계, 전파, 거버넌스 보호가 중요함
같은 공격 형식이더라도 단일 에이전트보다 다중 에이전트에서 더 큰 피해가 발생한다. 피해가 로컬에서 네트워크 전체로 전파됨
ACE(NDSS 2026)
답글 남기기